Implementing a live distributed antenna system (das) configuration from a virtual das design using an original equipment manufacturer (oem) specific software system in a das

ABSTRACT

Implementing a live wireless communication system configuration from a virtual wireless communication system design using an original equipment manufacturer (OEM) specific software system in a real wireless communication system is disclosed herein. In exemplary aspects disclosed herein, the OEM specific software system enables a designer to create, save, import, modify and/or preconfigure a virtual wireless communication system in a virtual wireless communication system configuration file(s) using OEM specific software tools resident in the real wireless communication system. The OEM specific software tools could include functionality such as the ability to incorporate and enforce OEM design constraints of the real wireless communication system. The configuration file(s) can then be subsequently implemented to modify and/or configure live equipment of a real wireless communication system.

PRIORITY APPLICATION

This application is a continuation of U.S. application Ser. No.15/332,603, filed Oct. 24, 2016, which claims the benefit of priorityunder 35 U.S.C. §119 of U.S. Provisional Application No. 62/329,592,filed on Apr. 29, 2016, the contents of which are relied upon andincorporated herein by reference in their entireties.

BACKGROUND

The disclosure relates to implementing distributed antenna systems(DAS), and more particularly to implementing a live DAS configurationfrom a virtual DAS design using an original equipment manufacturer (OEM)specific software system in a DAS.

Wireless customers are increasingly demanding wireless communicationsservices, such as cellular communications services and Wi-Fi services.Thus, small cells, and more recently Wi-Fi services, are being deployedindoors. At the same time, some wireless customers use their wirelesscommunication devices in areas that are poorly serviced by conventionalcellular networks, such as inside certain buildings or areas where thereis little cellular coverage. One response to the intersection of thesetwo concerns has been the use of distributed antenna systems (DASs). ADAS usually includes a head-end unit (HEU) connected to remote equipment(e.g., remote access units (RAU), remote hub units (RHU), etc.) therebycreating antenna coverage areas for establishing communications withwireless client devices located therein. In particular, the RAUs areconfigured to receive and transmit communications signals to clientdevices within the antenna range of the RAUs. DASs can be particularlyuseful when deployed inside buildings or other indoor environments wherethe wireless communication devices may not otherwise be able toeffectively receive radio frequency (RF) signals from a source.

In this regard, FIG. 1 illustrates a wireless distributed communicationssystem (WDCS) 100 that is configured to distribute communicationsservices to remote coverage areas 102(1)-102(N), where ‘N’ is the numberof remote coverage areas. The WDCS 100 in FIG. 1 is provided in the formof a DAS 104. The DAS 104 can be configured to support a variety ofcommunications services that can include cellular communicationsservices, wireless communications services, such as RF identification(RFID) tracking, Wireless Fidelity (Wi-Fi), local area network (LAN),and wireless LAN (WLAN), wireless solutions (Bluetooth, Wi-Fi GlobalPositioning System (GPS) signal-based, and others) for location-basedservices, and combinations thereof, as examples. The remote coverageareas 102(1)-102(N) are created by and centered on RAUs 106(1)-106(N)connected to a centralized equipment 108 (e.g., a head-end controller, acentral unit, or a head-end unit). The centralized equipment 108 may becommunicatively coupled to a source transceiver 110, such as forexample, a base transceiver station (BTS) or a baseband unit (BBU). Inthis regard, the centralized equipment 108 receives downlinkcommunications signals 112D from the source transceiver 110 to bedistributed to the RAUs 106(1)-106(N). The downlink communicationssignals 112D can include data communications signals and/orcommunication signaling signals, as examples. The centralized equipment108 is configured with filtering circuits and/or other signal processingcircuits that are configured to support a specific number ofcommunications services in a particular frequency bandwidth (i.e.,frequency communications bands). The downlink communications signals112D are communicated by the centralized equipment 108 over acommunications link 114 (e.g., one or more communication links) overtheir frequency to the RAUs 106(1)-106(N).

With continuing reference to FIG. 1, the RAUs 106(1)-106(N) areconfigured to receive the downlink communications signals 112D from thecentralized equipment 108 over a communications link 114. The downlinkcommunications signals 112D are configured to be distributed to therespective remote coverage areas 102(1)-102(N) of the RAUs106(1)-106(N). The RAUs 106(1)-106(N) are also configured with filtersand other signal processing circuits that are configured to support allor a subset of the specific communications services (i.e., frequencycommunications bands) supported by the centralized equipment 108. In anon-limiting example, the communications link 114 may be a wiredcommunications link, a wireless communications link, or an opticalfiber-based communications link. Each of the RAUs 106(1)-106(N) mayinclude an RF transmitter/receiver (not shown) and a respective antenna116(1)-116(N) operably connected to the RF transmitter/receiver towirelessly distribute the communications services to user equipment (UE)118 within the respective remote coverage areas 102(1)-102(N). The RAUs106(1)-106(N) are also configured to receive uplink communicationssignals 112U from the UE 118 in the respective remote coverage areas102(1)-102(N) to be distributed to the source transceiver 110.

Designers of DAS systems use third party software to create RF designsthat provide recommended configurations for placement and settings ofremote equipment (e.g., RAUs or RHUs). These RF designs are used byinstallers to perform initial installations of equipment for a DAS. Thisremote equipment include remote units, including remote access unitsthat contains electronics (e.g., fiber transceivers, filters, poweramplifiers, built in antenna(s) or port(s)) to connect the remoteequipment to external antenna(s) that propagate RF signals. Among otherthings, the RF designs provide predicted output power per WirelessOperator (e.g., Wireless Carrier), and predicted individual channelpowers for various Wireless Operator protocols or technologies (e.g.,LTE, UMTS, CDMA, EVDo, GSM, etc.) at each remote device.

Once the RF design is complete, the DAS system installer and/orcommissioner (e.g., who commission and/or optimize the DAS system)attempts to construct and/or commission the DAS system to closely matchthe RF design. The installer connects the remote equipment at or nearthe locations indicated in the design. The commissioner can calibratesettings for the DAS system components (e.g., remote equipment) per themanufacturer specific instructions. Placement and settings can be variedfrom the RF design according to the environment and experience of thecommissioner. The commissioner integrates (e.g., connects) the equipmentto distribute live signals (provided from wireless operator signalsource equipment (and/or other equipment)) into DAS head-end components(e.g., the Radio Interface Module(s) (RIM), power conditioner(s), etc.).The commissioner also optimizes output power of the remote equipment(e.g., RAUs or RHUs) per the wireless operator technology and/orprotocol.

The third party RF design software may allow designers to completesystem designs that violate DAS manufacturer specific software andhardware configuration requirements. Such RF design errors can lead tounplanned delays and/or unplanned systems costs from an inability toimplement the system as originally designed. For example, the installerand/or commissioner may be required to obtain additional components tocomplete DAS installation and/or commissioning. Further, the layout andlocation of the HEU and other components within the equipment racks andmodules within the cassis are left to the discretion of the installer.The installer may mount and install system components in a way that isdifferent than the intended design (whether or not properly documentedby the designer). As a result, it may be required to re-rack equipmentor reposition modules within the cassis, which could invalidatecommissioning of the system. Further, the DAS system design may notinclude information regarding how to configure DAS manufacturer specificsystem components through DAS manufacturer specific software interfaces(e.g., web-accessible graphical user interface (GUI), local GUI, etc.).Thus, the commissioner may configure the DAS equipment settings in asuboptimal manner (e.g., signal(s) does not reach the intended remotelocation(s), RF propagated at unintended power levels, etc.).

SUMMARY

Embodiments of the disclosure are directed to implementing a livedistributed antenna system (DAS) configuration from a virtual DAS designusing an original equipment manufacturer (OEM) specific software systemin a real DAS. The OEM specific software can be resident software in theDAS or accessible by the DAS. In exemplary aspects disclosed herein, theOEM specific software system enables a designer to create, save, import,modify and/or preconfigure a virtual DAS in a virtual DAS configurationfile(s) using OEM specific software tools resident in the real DAS. TheOEM specific software tools could include functionality such as theability to incorporate and enforce data, information, specifications,and/or limitations of the real DAS (e.g., OEM design constraints) forexample, to facilitate design and optimization of the virtual DAS forimproved and optimized performance of the real DAS. The configurationfile(s) can then be subsequently implemented to modify and/or configurelive equipment of a real DAS (e.g., to automatically calibrate the liveequipment). Additionally, the configuration file(s) could guide a userthrough installation of the real DAS equipment to ensure properinstallation thereof. The OEM specific software tools and localexecution of the virtual DAS facilitates, improves, and optimizes DASdesign and execution, and ensures that the real DAS substantiallymatches the DAS design. Thus, errors associated with design,installation, commissioning, and/or optimization may be reduced, andperformance improved and optimized.

One embodiment is a system for implementing a live DAS configurationfrom a virtual DAS design using an OEM specific software system in areal DAS. The system comprises a real DAS comprising signal distributionequipment and an OEM specific software system. The signal distributionequipment includes a head-end unit that comprises a processor, a memorycoupled to the processor, and a display device coupled to the processor.The OEM specific software system is electronically stored in the memoryof the real DAS, and is configured to execute processing steps. Theprocessor is configured to configure at least one virtual DAS settingfor a virtual DAS. The processor is also configured to enforce upon theat least one virtual DAS setting OEM, design constraints of at least onereal setting of signal distribution equipment in the real DAS. Theprocessor is further configured to generate at least one virtual DASconfiguration file comprising the at least one virtual DAS setting forthe virtual DAS. The processor is further configured to store the atleast one virtual DAS configuration file in the memory at the real DAS.The processor is further configured to modify the at least one realsetting of the signal distribution equipment in the real DAS based onthe at least one virtual DAS setting in the at least one virtual DASconfiguration file.

An additional embodiment of the disclosure relates to a method forimplementing a live DAS configuration from a virtual DAS design using anOEM specific software system in a real DAS. The method comprisesconfiguring, by an OEM specific software system in a real DAS, at leastone virtual DAS setting for a virtual DAS, and enforcing, by the OEMspecific software system, upon the at least one virtual DAS setting OEMdesign constraints of at least one real setting of signal distributionequipment in the real DAS. The method further comprises generating, bythe OEM specific software system, at least one virtual DAS configurationfile comprising the at least one virtual DAS setting for the virtualDAS, and storing, by the OEM specific software system, the at least onevirtual DAS configuration file in memory at the real DAS. The methodfurther comprises modifying, by the OEM specific software system, the atleast one real setting of the signal distribution equipment in the realDAS based on the at least one virtual DAS setting in the at least onevirtual DAS configuration file.

An additional embodiment of the disclosure relates to a non-transitorycomputer readable medium comprising program instructions forimplementing a live DAS configuration from a virtual DAS design using anOEM specific software system in a real DAS. The program instructions,when executed, comprise the processing steps of configuring, by an OEMspecific software system in a real DAS, at least one virtual DAS settingfor a virtual DAS, and enforcing, by the OEM specific software system,upon the at least one virtual DAS setting OEM design constraints of atleast one real setting of signal distribution equipment in the real DAS.The program instructions, when executed, further comprise the processingsteps of generating, by the OEM specific software system, at least onevirtual DAS configuration file comprising the at least one virtual DASsetting for the virtual DAS, and storing, by the OEM specific softwaresystem, the at least one virtual DAS configuration file in memory at thereal DAS. The program instructions, when executed, further comprise theprocessing steps of modifying, by the OEM specific software system, theat least one real setting of the signal distribution equipment in thereal DAS based on the at least one virtual DAS setting in the at leastone virtual DAS configuration file.

Additional features and advantages will be set forth in the detaileddescription which follows, and in part will be readily apparent to thoseskilled in the art from that description or recognized by practicing theembodiments as described herein, including the detailed descriptionwhich follows, the claims, as well as the appended drawings.

It is to be understood that both the foregoing general description andthe following detailed description are merely exemplary, and areintended to provide an overview or framework to understanding the natureand character of the claims. The accompanying drawings are included toprovide a further understanding, and are incorporated in and constitutea part of this specification. The drawings illustrate one or moreembodiments, and together with the description serve to explainprinciples and operation of the various embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of an exemplary wireless distributedcommunications system (WDCS) in the form of a distributed antenna system(DAS);

FIG. 2 is a schematic diagram of an exemplary optical fiber-based DAS,including an exemplary head-end unit (HEU) configured to distributeradio-frequency (RF) signals to a remote access unit (RAU);

FIG. 3 is a schematic diagram of an exemplary real DAS system thatincludes a head-end control module configured to provide head-endequipment for distributing and receiving RF communications signals toand from RAUs;

FIG. 4 is a schematic diagram of an exemplary RF path allocation betweenradio interface modules (RIMs) of the HEU and RAUs in the real DAS ofFIG. 3;

FIG. 5 is a schematic diagram of an exemplary RF path allocation betweenRIMs of the HEU and RAUs at a remote site using an FMM (fiber mainmodule)-to-FRM (fiber remote module) link in the real DAS of FIG. 3;

FIG. 6 is a front view of an exemplary integrated head-end unit (IHU)with an installed head-end control module (HCM) that can be employed inthe real DAS of FIG. 3 for distributing and receiving RF communicationssignals to and from RAUs;

FIG. 7 is a flowchart illustrating an exemplary process for implementinga live DAS configuration from a virtual DAS design using an originalequipment manufacturer (OEM) specific software system of the real DAS ofFIGS. 2 and 3;

FIG. 8 is a flowchart illustrating an exemplary process for configuringa new virtual DAS (profile) using the OEM specific software system ofthe real DAS of FIGS. 2 and 3 according to one embodiment;

FIG. 9 is an exemplary HCM controller login graphical user interface(GUI) page provided by the OEM specific software system of the HEU ofthe real DAS of FIGS. 2 and 3 for further access the OEM specificsoftware system;

FIG. 10 is an exemplary profile management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating profile management options for creating and/or editing avirtual DAS (profile);

FIG. 11 is an exemplary profile management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating profile options;

FIG. 12 is an exemplary profile management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating addition of a new site to a virtual DAS (profile);

FIG. 13 is an exemplary profile management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating defining site elements for a site;

FIGS. 14A-14K are exemplary profile management pages provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating adding, editing, and/or removing a chassis and/or modulefrom a site in a virtual DAS (profile);

FIG. 15 is an exemplary profile management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating addition of a remote to a virtual DAS (profile);

FIG. 16 is an exemplary profile management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3after a remote has been added to the virtual DAS (profile);

FIG. 17 is an exemplary profile management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating manual activation of a virtual DAS (profile);

FIG. 18 is an exemplary profile management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating connecting fiber main modules (FMM) to fiber remote modules(FRM) in a virtual DAS (profile);

FIG. 19 is an exemplary profile management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating a successful connection between a source and destinationsite in a virtual DAS (profile);

FIG. 20 is a flowchart illustrating an exemplary process for modifyingsite settings for commissioning at least one site in a virtual DAS(profile) using the OEM specific software system of the real DAS ofFIGS. 2 and 3;

FIG. 21 is an exemplary site configuration page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating site configuration settings for a site configuration phase;

FIG. 22 is an exemplary site configuration page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating a module owner subphase of the site configuration phase;

FIG. 23 is an exemplary site configuration page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating a MIMO (multiple-input multiple-output) setup subphase ofthe site configuration phase;

FIG. 24 is an exemplary site configuration page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating RF path configuration setup subphase of the siteconfiguration phase;

FIG. 25 is an exemplary site configuration page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating a max-input configuration setup subphase of the siteconfiguration phase;

FIG. 26 is an exemplary site configuration page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating a selected layer for a link RF path of the siteconfiguration phase;

FIG. 27 is an exemplary site configuration page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating amplifier sharing settings of an amplifier setting phase;

FIG. 28 is an exemplary site management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating a campus view for site management;

FIG. 29 is an exemplary site management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating a site view for site management;

FIG. 30 is an exemplary site management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating a rack view for site management;

FIG. 31 is an exemplary site management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating PAM (priority alarm message) alarms and alarmconfigurations;

FIG. 32 is an exemplary site management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating RF parameter configurations;

FIG. 33 is an exemplary site management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating a location map for displaying geographical locationinformation for configured sites of a virtual DAS;

FIG. 34 is an exemplary site management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating placement of a remote to a desired location on a floorblueprint of a building for a virtual DAS;

FIG. 35 is an exemplary site management page provided by the OEMspecific software system of the HEU of the real DAS of FIGS. 2 and 3illustrating module information for a selected remote of a virtual DAS;

FIG. 36 is a schematic diagram of an exemplary WDCS provided in the formof an optical fiber-based DAS;

FIG. 37 is a partially schematic cut-away diagram of an exemplarybuilding infrastructure in which a WDCS can be provided; and

FIG. 38 is a schematic diagram of a generalized representation of anexemplary computer system that can be included in any component in aWDCS and/or DAS.

DETAILED DESCRIPTION

Reference will now be made in detail to the present preferredembodiments, examples of which are illustrated in the accompanyingdrawings. Whenever possible, the same reference numerals will be usedthroughout the drawings to refer to the same or like parts. Oneembodiment of an original equipment manufacturer (OEM) specific softwaresystem is shown in FIG. 2, and is designated generally throughout by thereference numeral 200.

Embodiments of the disclosure are directed to implementing a livedistributed antenna system (DAS) configuration from a virtual DAS designusing an OEM specific software system in a real DAS. The OEM specificsoftware can be resident software in the DAS or accessible by the DAS.In exemplary aspects disclosed herein, the OEM specific software systemenables a designer to create, save, import, modify and/or preconfigure avirtual DAS in a virtual DAS configuration file(s) using OEM specificsoftware tools resident in the real DAS. The OEM specific software toolscould include functionality such as the ability to incorporate andenforce data, information, specifications, and/or limitations of thereal DAS (e.g., OEM design constraints) for example, to facilitatedesign and optimization of the virtual DAS for improved and optimizedperformance of the real DAS. The configuration file(s) can then besubsequently implemented to modify and/or configure live equipment of areal DAS (e.g., to automatically calibrate the live equipment).Additionally, the configuration file(s) could guide a user throughinstallation of the real DAS equipment to ensure proper installationthereof. The OEM specific software tools and local execution of thevirtual DAS facilitates, improves, and optimizes DAS design andexecution, and ensures that the real DAS substantially matches the DASdesign. Thus, errors associated with design, installation,commissioning, and/or optimization may be reduced, and performanceimproved and optimized.

In aspects disclosed herein, the OEM specific software system (e.g., DASmanufacturer OEM specific software system) enables a DAS designer tocreate a virtual DAS (e.g., which could be referred to as a “Profile”)and/or upload or import an existing real DAS to create a virtual DAS.The DAS designer can then modify the virtual DAS (e.g., adding orremoving buildings or DAS components, reconfiguring user definablesettings for the virtual DAS or DAS components, etc.). The userdefinable settings of the virtual DAS include equipment layout andphysical connectivity between (1) system components and/or (2) moduleswithin rooms, racks, or chassis. The virtual DAS can include componentsbeing physically located in multiple buildings or structures as well asoutdoor locations. The OEM specific software system may further enablepre-configuration of some or all user definable settings in the virtualDAS in advance of the virtual DAS being activated on a real DAS (e.g.,live DAS, active DAS, etc.), or prior to the real DAS being otherwisedeployed.

The virtual design profile within the DAS OEM specific software can becreated at one location or on one system, and can be loaded onto anothersystem at the same or different location either locally at a DAS systemsite(s) or through internet connections. A bill of materials of systemcomponents may be generated automatically or manually for the virtualcomponents within the virtual DAS, or from modifications to the virtualDAS (e.g., of an existing system), such as if a virtual component moves,is added, or otherwise changes. This can simplify procurement ofequipment (e.g., signal distribution equipment, real equipment, etc.)for the real DAS.

The OEM specific software system may further enable a user (e.g.,designer) to create virtual placeholders for equipment (e.g., RadioInterface Module(s) (RIMs), Optical Interface Module(s) (OIMs), RemoteAccess Units, which may be Remote Antenna Units (RAUs) for example orother remote equipment, fiber connectivity module(s) (FCMs), etc.) toreserve and preconfigure settings for future planned equipment to beadded later to the real DAS. For example, if only one wireless operatorjoins the system after the initial commissioning, but another wirelessoperator is expected to join the system at a later date, having virtualplaceholders for equipment (e.g., gear) would allow additional equipmentto be seamlessly added to the real DAS at a later date without the needfor a change to most, if not all, of the system configuration settings.

The OEM specific software system enables a user to adjust or preset anyof the user definable virtual settings in a virtual placeholdercomponent (e.g., like equipment). The virtual settings for equipment(e.g., RAU, FCM link, other remote equipment, etc.) would beautomatically uploaded (e.g., applied, activated, etc.) to equipmentonce connected or otherwise put in communication with the OEM specificsoftware system (e.g., positioned inside of a slot(s) in a chassis,connected by optical fiber(s), upon manual activation of the component,etc.). Virtual placeholders for future equipment could be configured tonot generate or mask associated system monitoring alarms, such as thosefor missing active equipment. The OEM specific software system may alsoautomatically calculate and/or modify (e.g., compensate or adjust)attenuator or gain settings within placeholder and existing componentsto automatically compensate for anticipated gains or losses in equipmentfor reasons such as amplifier sharing in advance of placeholdercomponents being replaced by equipment, or if placeholder or existingcomponents are removed from the system.

Once completed, the virtual DAS can be uploaded onto and activated intothe memory of the real DAS (e.g., real DAS manufacturer specific systemcontroller hardware, new or existing equipment, etc.), whether on a newor existing system. In certain embodiments, the virtual DAS (e.g.,profile, virtual design profile, etc.) has no impact on active or livesystem settings until the user “activates” or uploads the virtualsettings into the live or active system hardware. The OEM specificsystem user interface or graphical user interface (GUI) could guide theinstaller(s) through the installation process of the DAS components sothat the real DAS (e.g., active DAS, live DAS, etc.) matches that of thevirtual DAS, such as by guiding an installer through connection ofequipment (e.g., DAS components, DAS modules, etc.), their physicallocation(s) (e.g., placement of components within an equipment rack,placement of equipment modules within a chassis or chassis slot, etc.),etc. The OEM specific software system could also guide an installer asto RF, optical, and communication cable connections between multiplechassis and head-end to remote location or multi-building connections,where to physically place remote equipment on a map or building floorplan diagram, etc.

In particular, the OEM specific software system could provide feedback(e.g., confirmation messages, error messages, successful installationmessages, unsuccessful installation messages, etc.) if the installercorrectly or incorrectly installs or connects equipment (e.g., whetherthe equipment or module(s) are in the proper physical location, chassis,or chassis slot). Monitoring of installation by the OEM specificsoftware system could be from electrical or optical connections betweencomponents, from location based service detection (e.g., Bluetoothtransceivers, RFID, GPS), etc. Such feedback could include visualindicators such as text, symbols, color coded indicators, or audibleindicators. The OEM specific software system could also provide guidanceon installation of individual components, or multiple componentssimultaneously. For example, the installation instruction or guidancefrom the user interface could show a diagram of all modules that are tobe installed inside of a chassis simultaneously. As the user slidesmodules individually inside of the chassis, the user could receivefeedback that the installation of those modules was successful orunsuccessful.

The commissioning process (e.g., integration and/or optimization of livesignals or protocols) for the real DAS could be simplified and completedmore efficiently. For example, user definable downlink (DL) maximumexpected input power settings or attenuator settings at the point ofinterface equipment could be commissioned through the OEM specificsoftware system. DAS manufacturer specific settings can include singleor multiple RF path configurations, power amplifier settings, attenuatorsettings, and expected maximum and idle RF input power settings at pointof interface modules, such as RIM(s) or conditioners that connect withincoming signals provided by Wireless Operator equipment (e.g., BaseStation(s), Small Cell(s), BBU(s), Remote Radio Head(s) (RRH) or MetroCell(s), etc.). The RF path configuration settings can open and closeswitches within the electronics at the head-end, directing digital, RF,or optical signals within head-end components to remote equipment.

In this regard, FIG. 2 is a schematic diagram of an exemplary embodimentof an optical fiber-based distributed antenna system (DAS) 200(hereinafter “real DAS 200”) with equipment 202 (e.g., signaldistribution equipment, real equipment, etc.) that includes exemplaryhead-end equipment 204 and a remote access unit (RAU) 206. A real DAS200 and equipment 202 mean that they are tangible (as opposed to avirtual DAS and virtual equipment which are non-tangible). Note that thereal DAS 200 can include multiple RAUs although only one RAU 206 isshown in FIG. 2. In this embodiment, the real DAS 200 that is configuredto create one or more antenna coverage areas for establishingcommunications with wireless client devices located in the RF range ofthe antenna coverage areas. The real DAS 200 provides RF communicationsservices (e.g., cellular services). In this embodiment, the real DAS 200includes the head-end equipment 204 in the form of a head-end unit (HEU)208, one or more of the RAUs 206, and a communications medium in theform of an optical fiber 210 that communicatively couples the HEU 208 tothe RAU 206 in this example. In one example, the HEU 208 is provided asa chassis with electronic equipment installed therein. The HEU 208 isconfigured to receive communications over downlink network link 214(e.g., communications medium, connection, wire, etc.) from a source orsources, such as a network 216 or carrier as examples, and provide suchcommunications to the RAU 206. The HEU 208 is also configured to returnuplink electrical RF communications signals 218U received from the RAU206, via network link 214, back to the source or sources. In thisregard, in this embodiment, the optical fiber 210 includes at least onedownlink optical fiber 212D to carry signals communicated from the HEU208 to the RAU 206, and at least one uplink optical fiber 212U to carrysignals communicated from the RAU 206 back to the HEU 208. One downlinkoptical fiber 212D and one uplink optical fiber 212U could be providedto support multiple channels each using wavelength-division multiplexing(WDM), as discussed in U.S. patent application Ser. No. 12/892,424 filedSep. 28, 2010 entitled “Providing Digital Data Services in OpticalFiber-Based Distributed Radio Frequency (RF) Communications Systems, andRelated Components and Methods,” incorporated herein by reference in itsentirety. Other options for WDM and frequency-division multiplexing(FDM) are also disclosed in U.S. patent application Ser. No. 12/892,424,any of which can be employed in any of the embodiments disclosed herein.

The real DAS 200 (e.g., optical fiber-based) has an antenna coveragearea 220 that can be substantially centered about the RAU 206. Theantenna coverage area 220 of the RAU 206 forms an RF coverage area 222.The HEU 208 is adapted to perform or to facilitate any one of a numberof wireless applications, including but not limited to Radio-over-Fiber(RoF), radio frequency identification (RFID), wireless local-areanetwork (WLAN) communication, public safety, cellular, telemetry, andother mobile or fixed services. Shown within the antenna coverage area220 is a client device 226 in the form of a mobile device as an example,which may be a cellular telephone as an example. The client device 226can be any device that is capable of receiving RF communication signals.The client device 226 includes an antenna 228 (e.g., a wireless card)adapted to receive and/or send electromagnetic RF communicationssignals.

With continuing reference to FIG. 2, to communicate the RFcommunications signals 218D over the downlink optical fiber 212D to theRAU 206, to in turn be communicated to the client device 226 in theantenna coverage area 220 formed by the RAU 206, the HEU 208 includes anelectrical-to-optical (E/O) converter 230. The E/O converter 230converts the downlink electrical RF communications signals 218D todownlink optical RF communications signals 224D to be communicated overthe downlink optical fiber 212D. The RAU 206 includes anoptical-to-electrical (O/E) converter 232 to convert received downlinkoptical RF communications signals 224D back to electrical RFcommunications signals to be communicated wirelessly through an antenna234 of the RAU 206 to client devices 226 located in the antenna coveragearea 220.

Similarly, the antenna 234 is also configured to receive wireless RFcommunications from the client devices 226 in the antenna coverage area220. In this regard, the antenna 234 receives wireless RF communicationsfrom the client devices 226 and communicates electrical RFcommunications signals representing the wireless RF communications to anE/O converter 236 in the RAU 206. The E/O converter 236 converts theelectrical RF communications signals into uplink optical RFcommunications signals 224U to be communicated over the uplink opticalfiber 212U. An 0/E converter 240 provided in the HEU 208 converts theuplink optical RF communications signals 224U into uplink electrical RFcommunications signals, which can then be communicated as uplinkelectrical RF communications signals 218U back to a network or othersource. The HEU 208 in this embodiment is not able to distinguish thelocation of the client devices 226. The client device 226 could be inthe range of any antenna coverage area 220 formed by an RAU 206.

With continuing reference to FIG. 2, the HEU 208 includes a service unit242, which may be a remote interface module (RIM), that provideselectrical RF service signals by passing (or conditioning and thenpassing) such signals from one or more outside networks 216 via anetwork link 214. In a particular exemplary embodiment, this includesproviding WLAN signal distribution as specified in the Institute ofElectrical and Electronics Engineers (IEEE) 802.11 standard, i.e., inthe frequency range from 2.4 to 2.5 GigaHertz (GHz) and from 5.0 to 6.0GHz. Any other electrical RF communications signal frequencies arepossible. In another exemplary embodiment, the service unit 242 provideselectrical RF service signals by generating the signals directly. Inanother exemplary embodiment, the service unit 242 coordinates thedelivery of the electrical RF service signals between client devices 226within the antenna coverage area 220.

With continuing reference to FIG. 2, the service unit 242 iselectrically coupled to the E/O converter 232 that receives the downlinkelectrical RF communications signals 218D from the service unit 242 andconverts them to corresponding downlink optical RF communicationssignals 224D. In an exemplary embodiment, the E/O converter 232 includesa laser suitable for delivering sufficient dynamic range for RoFapplications, and optionally includes a laser driver/amplifierelectrically coupled to the laser. Examples of suitable lasers for theE/O converter 232 include, but are not limited to, laser diodes,distributed feedback (DFB) lasers, Fabry-Perot (FP) lasers, and verticalcavity surface emitting lasers (VCSELs).

With continuing reference to FIG. 2, the HEU 208 also includes the O/Econverter 240, which is electrically coupled to the service unit 242.The O/E converter 240 receives the uplink optical RF communicationssignals 224U and converts them to corresponding uplink electrical RFcommunications signals 218U. In an exemplary embodiment, the O/Econverter 240 is a photodetector, or a photodetector electricallycoupled to a linear amplifier. The E/O converter 232 and the O/Econverter 240 are provided in an optical interface module (OIM) 238 inthis example.

In accordance with an exemplary embodiment, the service unit 242 in theHEU 208 can include an RF communications signal conditioner unit 240 forconditioning the downlink electrical RF communications signals 218D andthe uplink electrical RF communications signals 218U, respectively. Theservice unit 242 can include a digital signal processing unit (“digitalsignal processor”) 246 for providing to the RF communications signalconditioner unit 244 an electrical signal that is modulated onto an RFcarrier to generate a desired downlink electrical RF communicationssignal 218D. The digital signal processor 246 is also configured toprocess a demodulation signal provided by the demodulation of the uplinkelectrical RF communications signal 218U by the RF communications signalconditioner unit 244. The service unit 242 in the HEU 208 can alsoinclude an optional central processing unit (CPU) 248 for processingdata and otherwise performing logic and computing operations, and amemory unit 250 for storing data, such as data to be transmitted over aWLAN or other network for example. The HEU 208 also includes the OEMspecific software system 252, which could be stored in the memory unit250 and accessed and processed by the CPU 248.

With continuing reference to FIG. 2, the RAU 206 also includes aconverter pair 256 comprising the O/E converter 232 and the E/Oconverter 236. The O/E converter 232 converts the received downlinkoptical RF communications signals 224D from the HEU 208 back intodownlink electrical RF communications signals 258D. The E/O converter236 converts uplink electrical RF communications signals 258U receivedfrom the client device 226 into the uplink optical RF communicationssignals 224U to be communicated to the HEU 208. The O/E converter 232and the E/O converter 236 are electrically coupled to the antenna 234via an RF signal-directing element 260, such as a circulator forexample. The RF signal-directing element 260 serves to direct thedownlink electrical RF communications signals 258D and the uplinkelectrical RF communications signals 258U, as discussed below. Inaccordance with an exemplary embodiment, the antenna 234 can include oneor more patch antennas, such as disclosed in U.S. patent applicationSer. No. 11/504,999, filed Aug. 16, 2006 entitled “Radio-over-FiberTransponder With A Dual-Band Patch Antenna System,” now issued U.S. Pat.No. 7,627,250, and U.S. patent application Ser. No. 11/451,553, filedJun. 12, 2006 entitled “Centralized Optical-Fiber-Based WirelessPicocellular Systems and Methods,” both of which are incorporated hereinby reference in their entireties.

With continuing reference to FIG. 2, the real DAS 200 also includes apower supply 262 that generates an electrical power signal 264. Thepower supply 262 is electrically coupled to the HEU 208 for powering thepower-consuming elements therein. In an exemplary embodiment, anelectrical power line 266 runs through the HEU 208 and over to the RAU206 to power the O/E converter 232 and the E/O converter 236 in theconverter pair 256, the optional RF signal-directing element 260 (unlessthe RF signal-directing element 260 is a passive device such as acirculator for example), and any other power-consuming elementsprovided. In an exemplary embodiment, the electrical power line 266includes two wires 268 and 270 that carry a single voltage and that areelectrically coupled to a DC power converter 272 at the RAU 206. The DCpower converter 272 is electrically coupled to the O/E converter 232 andthe E/O converter 236 in the converter pair 256, and changes the voltageor levels of the electrical power signal 264 to the power level(s)required by the power-consuming components in the RAU 206. In anexemplary embodiment, the DC power converter 272 is either a DC/DC powerconverter or an AC/DC power converter, depending on the type ofelectrical power signal 264 carried by the electrical power line 266. Inanother exemplary embodiment, the electrical power line 266 (dashedline) runs directly from the power supply 262 to the RAU 206 rather thanfrom or through the HEU 208. In another exemplary embodiment, theelectrical power line 266 includes more than two wires and carriesmultiple voltages.

FIG. 3 provides additional information and equipment of the real DAS 200discussed above with respect to FIG. 2. More specifically, FIG. 3 is aschematic diagram of an exemplary real DAS 200 that includes a head-endcontrol module (HCM) 310 configured to provide head-end equipment fordistributing and receiving RF communications signals to and from RAUs206. The HCM 310 enables centralized, single-source local and remotemanagement of DAS equipment (e.g., ACMs). This particular embodiment ofthe real DAS 200 comprises a main site head-end 300, a remote site A302, a remote site B 304, and remote subsite B 306 (e.g., at remote siteB or proximate thereto). The main site head-end 300 comprises acontroller web session 308, used to access the OEM specific softwaresystem 252 via the HCM 310 over the network 216 (e.g., local areanetwork (LAN)). In certain embodiments, the HCM 310 is a part of themain HEU 208. The HCM 310 is connected to a first HEU 312 (withauxiliary control modules (ACMs)), a first optical interface unit (OIU)314 (with ACM), a second HEU 316 (with ACM), and a second OIU 318 (withACM) via management (MGMT) cables. The main HEU 208 is connected to afirst HEU 312 (with ACM), a first OIU 314 (with ACM), a second HEU 316(with ACM), and a second OIU 318 (with ACM) via coaxial cables.Connection of the HCM with four ACMs enables centralized management forall connected head-end and remote-end site elements.

The first OIU 314 and second OIU 218 are connected via a fiber opticcable(s) to a first ICU 320 at remote site A 302. The ICU 320 isconfigured to provide power for powering the RAUs 206. The ICU 320 maybe configured to provide the power in a composite cable along with theoptical fibers carry signals from the HEU 208 to the RAUs 206. The firstICU 320 is connected to one or more RAUs 206 that transmit downlinkelectrical RF communications signals 258D (each RAU 206 may include RFexpansion (remote expansion unit (RxU))). The second OIU 218 is alsoconnected to an integrated head-end unit (IHU) 322 (with ACM) at remotesite B 304 via an FMM-to-FRM fiber optic link. The IHU 322 (with ACM) isconnected to an ICU 324 at remote subsite B 306 by a fiber opticcable(s). The ICU 324 is connected via a fiber optic cable(s) to one ormore RAUs 206 that transmit downlink electrical RF communicationssignals 258D (each RAU 206 may include RF expansion (RxU)). The ICU 324could also be connected via a fiber optic cable to a mid-power remoteunit (MRU) 326 which then transmits downlink electrical RFcommunications signals 258D.

FIG. 4 is a schematic diagram of an exemplary RF path allocation betweenradio interface modules (RIMs) 406-418 of the HEU 208 and RAUs 206 inthe real DAS of FIG. 3. Multiple RIM modules can be assorted with asingle optical interface module (OIM) in each service group, and one RIMmodule can be associated with a number of OIMs in a service group. Forexample, in one embodiment, the RF paths for up to three service groups(e.g., service specific RIMs and/or OIMs) are configured. In thisexample, as shown, a head-end 300 includes a head-end unit (HEU) 208 andan OIU 420. The HEU 208 comprises a first service group 400, whichincludes the RIM #1 module 406, which is configured to transmitsupported Service A to OIM #4 module 422 of OIU 420. The OIM #4 module422 then transmits the supported Service A to RAUs 206A at remote end428 which then transmit Service A 258A to one or more client devices 226(not shown). The HEU 208 comprises a second service group 402, whichincludes RIM #1 module 408 and RIM #2 module 410, which are configuredto transmit corresponding Services A,B to OIM #5 module 424 of OIU 420.The OIM #5 module 424 then transmits the supported Services A,B to RAUs206B at remote end 428 which then transmit Services A,B 258B to one ormore client devices 226 (not shown). The HEU 208 comprises a thirdservice group 404, which includes RIM #1 module 412, RIM #2 module 414,RIM #3 module 416, and RIM #4 module 418, which are configured totransmit corresponding services A, B, C, D to OIM #6 module 426 of OIU420. The OIM #6 module 426 then transmits the supported Services A, B,C, D to RAUs 206C at remote end 428, which then transmit Services A, B,C, D 258C to one or more client devices 226 (not shown).

FIG. 5 is a schematic diagram of an exemplary RF path allocation betweenRIMs 406-418 of the HEU 208 and RAUs 206 at a remote site 504 using anFMM-to-FRM link in the real DAS of FIG. 3. More specifically, FIG. 5illustrates an example of RF paths configured for multiple sites, wherethe service signals are extended to a remote location via an FMM-FRMlink.

For example, in one embodiment, the RF paths for up to three servicegroups (e.g., service specific RIMs and/or OIMs) are configured. In thisexample, the service groups are configured both at the main head-end 300(e.g., main head-end site) and at the remote location (e.g., site 1 504)so that the services from the RIMs at the main head-end 300 are extendedto OIMs at the remote location and distributed by their connected RAUremotes.

In this example, as shown (similar to that of FIG. 4), a main head-end300 includes an HEU 208 and an OIU 500, and site 1 504 includes an HEU506 and an OIU 420. The HEU 208 comprises a first service group 400,which includes the RIM #1 module 406, which is configured to transmitsupported Service A to FMM 502 of OIU 500 of the main head-end 300. TheOIU FMM 502 then transmits the supported service A to a FRM 508 of theHEU 506 of site 1 504. The site 1 HEU FRM 508 then transmits service Ato OIM #4 module 422 of OIU 420. The OIM #4 module 422 then transmitsthe supported Service A to RAUs 206A at site 1 504, which then transmitService A 258A to one or more client devices 226 (not shown).

The HEU 208 comprises a second service group 402, which includes RIM #1module 408 and RIM #2 module 410, which are configured to transmitcorresponding Services A,B to FMM 502 of OIU 500 of the main head-end300. The OIU FMM 502 then transmits the supported services A,B to a FRM508 of the HEU 506 of site 1 504. The site 1 HEU FRM 508 then transmitsservice A to OIM #5 module 424 of OIU 420. The OIM #5 module 424 thentransmits the supported Services A,B to RAUs 206B at site 1 504, whichthen transmit Services A,B 258B to one or more client devices 226 (notshown).

The main head-end HEU 208 comprises a third service group 404, whichincludes RIM #1 module 412, RIM #2 module 414, RIM #3 module 416, andRIM #4 module 418, which are configured to transmit correspondingservices A, B, C, D to FMM 502 of OIU 500 of the main head-end 300. TheOIU FMM 502 then transmits the supported services A,B to a FRM 508 ofthe HEU 506 of site 1 504. The site 1 HEU FRM 508 then transmits serviceA to OIM #6 module 426 of OIU 420. The OIM #6 module 426 then transmitsthe supported Services A, B, C, D to RAUs 206C at site 1 504, which thentransmit Services A, B, C, D 258C to one or more client devices 226 (notshown).

FIG. 6 is a front view of an exemplary integrated head-end unit (IHU)600 with an installed head-end control module (HCM) 602 that can beemployed in the real DAS of FIG. 3 for distributing and receiving RFcommunications signals to and from RAUs 206. More specifically, the HCMmodule 602 is installed at a head-end element (e.g., HEU, IHU 600) atthe main site and enables centralized management and controlcapabilities of the DAS system. Auxiliary control modules (ACM) areinstalled in the remaining system head-end units and are interconnected(e.g., directly or indirectly) to the HCM enabling single sourcemanagement via the HCM. The HCM could be connected to one or more HEU,OIU, and/or IHU units, whether directly or indirectly. In largeconfigurations, the ACMs can be cascaded to each other.

In certain embodiments, the HCM module 602 interface comprises a consoleport 604, one or more internal ports (e.g., first internal port 606A,second internal port 606B, third internal port 606C, fourth internalport 606D, etc.), a LAN port 608, and/or a local port 610. The consoleport (e.g., RJ45, serial port) could be used for local configurations.The internal ports 606A-606D (e.g., RJ45, 100 Mb Ethernet ports) areused for management of connected ACMs installed in OIU chassis, HEUchassis, and/or IHU chassis. The ACM module interface would havecorresponding similar internal ports for connecting to the HCM moduleinterface 602. The LAN port 608 (e.g., RJ45, 1 Gb Ethernet port)connects to corporate LAN for remote management. The local port 610(e.g., RJ45, 1 Gb Ethernet port) could be used for local configurationand management.

The real DAS 200 discussed above can be configured using the OEMspecific software system 252 also discussed above. More specifically,the OEM specific software system 252 in the real DAS 200 can be used toimplement a live DAS configuration from a virtual DAS design. In thisregard, FIG. 7 is a flowchart of an exemplary process 700 forimplementing a live DAS configuration from a virtual DAS design using anOEM specific software system of the real DAS of FIGS. 2 and 3 accordingto one embodiment. More specifically, at step 702, the OEM specificsoftware system 252 in the real DAS 200 electronically configures atleast one virtual DAS setting for a virtual DAS. At step 704, the OEMspecific software system 252 electronically enforces upon the at leastone virtual DAS setting OEM design constraints of at least one realsetting of equipment in the real DAS 200. Thus, the OEM specificsoftware system 252 incorporates and enforces data, information,specifications, and/or limitations of the real DAS (e.g., OEM designconstraints) for example, to facilitate design and optimization of thevirtual DAS for improved and optimized performance of the real DAS. Instep 706, the OEM specific software system 252 electronically generatesat least one virtual DAS configuration file 254 comprising the at leastone virtual DAS setting for the virtual DAS. In step 708, the OEMspecific software system 252 electronically stores the at least onevirtual DAS configuration file in memory at the real DAS 200. In step710, the 252 electronically modifies the at least one real setting ofthe equipment in the real DAS 200 based on the at least one virtual DASsetting in the at least one virtual DAS configuration file. Accordingly,the OEM specific software system 252 and local execution of the virtualDAS facilitates, improves, and optimizes DAS design and execution, andensures that the real DAS substantially matches the DAS design. In step712, the OEM specific software system 252 electronically guides aninstaller through proper installation of the equipment of the real DAS200. Proper installation means that the real DAS 200 has been installedconsistent with the design of the virtual DAS in the configuration fileand the real DAS 200 has established communication among the equipment.In step 714, the OEM specific software system 252 determines whether thereal DAS 200 has been properly installed. If the real DAS 200 has notbeen properly installed, then in step 716, the OEM specific softwaresystem 252 electronically alerts the installer as to errors and/orelectronically guides the installer through corrections. Then, theprocess 700 reverts back to step 714. If the real DAS 200 has beenproperly installed in step 714, then in step 718, the OEM specificsoftware system 252 automatically self-calibrates the real DAS 200 toensure design compliance with the virtual DAS and/or to optimizeperformance of the real DAS 200 and the process 700 ends. Guiding a userthrough installation of the real DAS ensures compliance with the virtualDAS design. Thus, process 700 reduces errors associated with design,installation, commissioning, and/or optimization for improvedperformance and optimization of the real DAS 200.

As discussed above, the virtual DAS is used to configure equipment ofthe real DAS 200. FIG. 8 is a flowchart illustrating an exemplaryprocess 800 for configuring a new virtual DAS (profile) using the OEMspecific software system 252 of the real DAS 200 of FIGS. 2 and 3according to one embodiment. In step 802, the OEM specific softwaresystem 252 at a real DAS 200 electronically configures a new virtual DAS(profile). In step 804, the OEM specific software system 252electronically configures a new site for the virtual DAS. In step 806,the OEM specific software system 252 electronically configures sourceand destination sites of the virtual DAS. In step 808, the OEM specificsoftware system 252 determines whether the virtual DAS has been properlyconfigured. If the virtual DAS has not been properly configured, then instep 810, the OEM specific software system 252 electronically alerts auser as to errors and/or electronically guides the user throughcorrections. Then the process 800 reverts back to step 808. If thevirtual DAS has been properly configured in step 808, then in step 812,the OEM specific software system 252 electronically transmits anotification to a user that the virtual DAS design is compliant and noerrors were found.

FIGS. 9-19 are exemplary pages of a user interface of the OEM specificsoftware system 252 for configuring a new virtual DAS (profile, virtualdesign profile, etc.) (as similarly described in FIG. 8). Morespecifically, FIG. 9 is an exemplary HCM controller login GUI page 900provided by the OEM specific software system 252 of the HEU 208 of thereal DAS 200 of FIGS. 2 and 3 for further access to the OEM specificsoftware system 252. The login page 900 could be accessed through theHCM local port 610 of the HCM module 602 of the IHU 600 (or HEU) (asdescribed above in FIG. 6). In certain embodiments, the login page 900can be accessed through a web browser of a computer connected to the IHU600 (or HEU) through the HCM local port 610. The login page 900comprises a user name field 902, a password field 904, and/or groupfield 906. Login credentials could be set to default values for firsttime users, and then changed after first time login. A user, systemcommissioner, or installer can log into the DAS manufacturer OEMspecific software system and upload and activate the settings andequipment configurations in the virtual DAS that was created by thesystem designer within DAS OEM specific software. A virtual DAS in avirtual DAS configuration file in the OEM specific software system canbe created, accessed, modified, uploaded, downloaded, or activatedlocally at a real DAS and/or remotely through the internet.

FIG. 10 is an exemplary profile management page 1000 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating profile management options for creating and/orediting a virtual DAS (profile). The profile management page 1000 maycomprise a number of tabs, such as a management tab 1002, events tab1004, configuration tab 1006, administration tab 1008, profiles tab1010, location tab 1012, multilink tab 1014, and/or a help tab 1016. Themanagement tab 1002 enables a user to view and configure networktopologies, device alarms, and/or other management options. The eventstab 1004 enables a user to view and configure events that occurred onthe monitored devices. The configuration tab 1006 enables a user toconfigure and commission installed system devices and adjustmentprocedure. The administration tab 1008 provides a user withadministration options, such as firmware upgrades, user managementoptions, IP settings (e.g., required for receiving traps), etc. Theprofiles tab 1010 enables a user to create a virtual DAS (profile)offline and then activate it at a later time. Each virtual DAS includesvirtual DAS equipment (e.g., a physical configuration on the installedunits) and virtual DAS settings (e.g., commissioning parameters). Whenthe virtual DAS is activated, the OEM specific software system couldprovide step-by-step instructions on how to configure the system. Thelocation tab 1012 enables a user to import maps and icons to graphicallydisplay the geographical location and types of sites, as well as thefloor plans and map power settings for the system elements. Themultilink tab 1014 enables managing and accessing multiple setups in thesame network from a single point of management (e.g., enables performingspecific operations on a plurality of connected HCMs). The help tab 1016provides access to online help files and other resources.

To configure a new profile (via a GUI) using the OEM specific softwaresystem, a user first selects the profiles tab 1010, which then displaysprofile options area 1018 and a profiles list 1028. A profile is aprofile configuration of a virtual DAS created for, linked with, and/orderived from a real DAS. In other words, a profile is a virtual DAS. Inparticular, the profile may include virtual DAS equipment and settingspertaining to physical installation, connection requirements, and/orcommissioning, etc. The profiles tab 1010 electronically provides a GUIfor a user to manage, create, delete, copy, and/or export a profile.Upon completing the profile configuration of the virtual DAS, thevirtual DAS can then be activated, and the OEM specific software system252 may guide an installer with step-by-step instructions on how tosetup the real DAS, and may apply the profile configuration on the realDAS. After the profile has been successfully activated, the system canbe adjusted via the configuration tab 1006.

The profile options area 1018 electronically displays to the userseveral options for interactive selection, such as creating a newprofile 1020, creating a new profile from baseline 1022, creating a newprofile from third party platform 1024, and/or importing a profile 1026.Creating a new profile 1020 enables the user to create a completely newprofile. Creating a new profile from baseline 1022 enables a user tocreate a new profile based on the configuration of the existing onlinesystem in use. In other words, creating a new profile from baseline 1022enables a user to quickly create a profile which can be subsequentlyedited according to site requirements. Creating a new profile from thirdparty platform 1024 enables a user to load an electronic third partyplatform design (e.g., third party platform file), which could includeantenna locations and/or antenna deployment. More specifically, thethird party platform design could include floor layouts and/or setupdesign, and could be used as is or as a baseline configuration (to befurther modified). Importing a profile 1026 enables a user to import aprofile previously created and exported using the OEM specific softwaresystem 252.

The profiles list 1028 lists any profiles accessible to the user (e.g.,by previous creation, by access rights, etc.), and may also displayrelated information. For example, as illustrated in profile managementpage 1000 of FIG. 10, Profile_1 1030 is listed in the profiles list 1028and includes the status (e.g., OK) as of a particular date and time(e.g., 31/May/2016 05:16:35).

FIG. 11 is an exemplary profile management page 1100 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating profile options. More specifically, once a profilehas been created, edited, and/or selected, the OEM specific softwaresystem 252 shifts to offline mode, and a profile status 1102 of theprofile or the system is provided (e.g., Offline mode-Profile_1,“Operating in Offline Mode”, etc.). The profile status 1102 notifies theuser as to whether the profile is offline (not live) or online (live).Additionally, or alternatively, a color coded background can be used toindicate that the user (e.g., designer) is working within a virtual DASrather than on an active or live DAS.

The OEM specific software system 252 also provides a profileadministration subtab 1104 and a design subtab 1106. Under the profileadministration subtab 1104 is a profile options area 1108 providing aGUI for the user to save a profile 1110, exit without saving 1112,and/or import a third party platform file 1114 containing location mapsused to graphically display the geographical location of the site (e.g.,building) and the layout of each floor. The maps are utilized anddisplayed in the “Location” main menu screen, where remotes (e.g., RAU,MRU) can be assigned and placed on the maps, representing their actualphysical location in the floor plan.

FIG. 12 is an exemplary profile management page 1200 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating addition of a new site to a virtual DAS (profile).Under the design subtab 1106, the OEM specific software system 252electronically provides a GUI for a user to design a virtual DAS (e.g.,add or edit new sites). More specifically, the profile management page1200 provides a field for a user to add a new site 1202, provides theinstallation status 1204 of the new site, and provides a new siteoptions area 1206. The new site options area 1206 provides a number ofoptions and settings for configuring the new site, such as an add newsite general information section 1208, a number of components section1210, and/or remotes information section 1212, etc. For example, underthe add new site general information section 1208, a user can input thesite name (e.g., main), the site type (e.g., enterprise), etc. Under thenumber of components section 1210, a user can input the number of HEUs(e.g., 0-4), the number of OIUs (e.g., 0-4), the number of IHUs (e.g.,0-2), RIMs information, and/or DIMs information, etc. More specifically,the RIMs information could include the number of different types ofRIMs, such as for each supported service to be installed (e.g., 0-48).For example, a user could input the number of RIMs to support 700,700-MMO, AWS, AWS3, AWS-MMO, PCS, CELL, WCS, and/or CELL/ESMP, etc.

The remotes information section 1212 enables a user to input the numberof FMMs (e.g., 0-8) and/or the number of FRMs (e.g., 0-8), as well asselect any additional add-ons, such as input the number of RAU5 units(e.g., 0-144), enable (or disable) the RAUX option if installed, enable(or disable) the RXU option if installed, etc. The remotes informationsection 1212 may also enable the user to input the number of MRUs(0-144) and/or select the bands supported by the one or more MRUs (e.g.,PCS, AWS, AWS3, 700, WCS, Cell/ESMR, etc.).

FIG. 13 is an exemplary profile management page 1300 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating defining site elements for a site. Morespecifically, the profile management page 1300 illustrates configuring(e.g., added, moved, removed, changed, etc.) a chassis and modules of asite (e.g., if the profile is based on a baseline configuration). Inparticular, illustrated is a chassis drop down menu 1302 to add achassis (e.g., to add a particular type of chassis). As shown, theexemplary profile includes a first HEU module 1306A with first HEUmodules 1306A, a second HEU chassis 1306B with second HEU modules 1306B,a first OIU chassis 1308A with first OIU chassis modules 1310A, and asecond OIU chassis 1308B. Further, the exemplary profile includes firstoptical port 1312A, second optical port 1312B, and third optical port1312C. As shown, the optical ports 1312A, 1312B, 1312C have not yet beenconfigured.

FIGS. 14A-14K are exemplary profile management pages provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating adding, editing, and/or removing a chassis and/ormodule. In particular, the OEM specific software system 252 enables auser to select the type of chassis, the type of modules therein, theplacement of those modules within the chassis, etc.

In this regard, FIG. 14A is a chassis submenu 1400A enabling a user toselect the type of chassis to add (e.g., HEU, OIU, IHU, etc.). FIG. 14Bis a module submenu 1400B enabling a user to select a type of module toadd (e.g., RIM, FRM) for an HEU chassis. FIG. 14C is a module submenu1400C enabling a user to select a type of module to add (e.g., RIM, FRM,FMM, etc.) for an IHU chassis. FIG. 14D is a module submenu 1400Denabling a user to select the RIM band (e.g., PCS, CELL, AWS, AWS-MIMO,700, 700-MIMO, CELL/ESMR, WCS, etc.) for a RIM module. FIG. 14E is amodule submenu 1400E enabling a user to add a module (e.g., OIM, FMM,etc.) for an OIU chassis. FIG. 14F is a module submenu 1400F enabling auser to add a module (e.g., OIM, RIM, FRM, FMM, etc.) for an IHUchassis. FIG. 14G is a module submenu 1400G enabling a user to remove amodule. FIG. 14H is a chassis submenu 1400H enabling a user to delete achassis. FIG. 14I is a module submenu 1400I enabling a user to set acontrol module as the HCM, such as by selecting a module and the OEMspecific software system 252 presenting a number of operation options toa user (e.g., delete chassis, set as HCM, etc.). FIG. 14J is a modulesubmenu 1400J enabling a user to change RIX/OIX to ETM. FIG. 14K is amodule submenu 1400K enabling a user to remove an ERFC connection (e.g.,of an RIX or OIX).

FIG. 15 is an exemplary profile management page 1500 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating addition of a remote to a virtual DAS (profile). Asshown, the profile also includes a first optical port 1312A, a secondoptical port 1312B, and a third optical port 1312C. Each of the opticalports 1312A, 1312B, 1312C enable a user to add a remote to the opticalport 1312A, 1312B, 1312C by add module subwindow 1502, which includes adrop down menu of types of remotes to add (e.g., RAUS, RAUS+RXU, RAUX,RAUX+RXU, RAUS+RXUTOO, RAUX+TOO, MRU, MRU-AWS3, etc.).

FIG. 16 is an exemplary profile management page 1600 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 after a remote 1602 has been added to the virtual DAS (profile)(e.g., at a first optical port 1512A).

FIG. 17 is an exemplary profile management page 1700 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating manual activation of a virtual DAS (profile). Morespecifically, manual activation mode 1702 may be required if an error isfound in the profile at the time of activation of the profile. Themanual activation mode 1702 of the OEM specific software system 252includes an error alert section 1704 to alert a user that an error wasfound (e.g., “An error occurred please fix the problem or select one ofoption from the control panel in order to finish the activation”). TheOEM specific software system 252 then guides a user through eachdetected error that requires correction at the correction guide section1706. A user can click the ignore button 1708 to ignore the errorcurrently displayed and continue to the next error. A user can click theignore all button 1710 to skip all minor errors that prevent the profilefrom being successfully activated. A user can click the cancel button1712 to quit manual activation and return to another screen. The OEMspecific software system 252 notifies the user once all the errors arecorrected or, at the minimum, if all the major errors are corrected.

FIG. 18 is an exemplary profile management page 1800 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating connecting fiber main modules (FMM) to fiber remotemodules (FRM) in a virtual DAS (profile). More specifically, the profilemanagement page 1800 provides an installation status 1802 (e.g.,“There's an installation fault in the system.”). Using the OEM specificsoftware system 252, and after all the sites are added to the profile,source and destination sites can be determined and connected, where eachof the sites include the appropriate FMM and FRM modules forconnectivity. A user can select the site management option 1803 underthe design subtab 1106 under the profiles tab 1010. Using the OEMspecific software system 252, a user can select a first module 1808(e.g., FMM module) of a first chassis 1804 (e.g., OIU chassis) of asource site (e.g., source site-main) and then select a second module1810 (e.g., FRM module) of a second chassis 1806 (e.g., IHU chassis) ofa destination site (e.g., destination site-remote), and clicks theconnect button 1812 to create an FMM-to-FRM connection between the twomodules. The OEM specific software system 252 could guide a user throughconnecting the modules by indicating which modules are available forconnection. For example, in certain embodiments, a gray module indicatesthat the module is available for connection, a green highlight indicatesthat the module is selected to be connected, etc.

FIG. 19 is an exemplary profile management page 1900 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating a successful connection between a source anddestination site in a virtual DAS (profile). More specifically, theprofile management page 1900 provides a main site icon 1904 with a mainsite status indicator 1906 (e.g., red if the site is not properlyinstalled, green if the site is properly installed, etc.), and a remotesite icon 1908 with a remote site status indicator 1910 (e.g., red ifthe site is not properly installed, green if the site is properlyinstalled, etc.). Once the FMM-to-FRM connection between the two sitesis properly configured, a connection indicator can be used to indicate asuccessful connection between the two sites (e.g., a red arrow if theconnection is not properly configured, a green arrow if the connectionis properly configured, etc.).

FIG. 20 is a flowchart of an exemplary process 2000 for modifying sitesettings for commissioning at least one site of a virtual DAS (profile)using the OEM specific software system 252 of the real DAS 200 of FIGS.2 and 3. After defining the new site and selecting the system elementsto be configured for the site, the user uses the OEM specific softwaresystem 252 to configure as many system parameters as possible (e.g., inoffline mode) to provide a complete virtual DAS (e.g., systemconfiguration profile) to be applied and installed upon activation. Notethat the OEM specific software system 252 could provide an error messageif the virtual DAS has any errors in the configuration. However, theexemplary process 2000 could also be specified after the profile isactivated and the system is in online mode.

More specifically, in step 2002, the OEM specific software system 252electronically receives modifications to the site configuration settingsof a virtual DAS. The step may include several substeps. In certainembodiments, in substep 2004, the OEM specific software system 252electronically receives modifications to module owner settings of thevirtual DAS. In substep 2006, the OEM specific software system 252electronically receives modifications to (multiple-inputmultiple-output) (MIMO) setup settings of the virtual DAS. In substep2008, the OEM specific software system 252 electronically receivesmodifications to RF path settings of the virtual DAS. In substep 2010,the OEM specific software system 252 electronically receivesmodifications to max input settings of the virtual DAS.

Continuing to step 2012, the OEM specific software system 252electronically receives modifications to amplifier sharing settings ofthe virtual DAS. In step 2014, the OEM specific software system 252electronically receives modifications to antenna settings of the virtualDAS. In step 2016, the OEM specific software system 252 electronicallyreceives modifications to run-time settings of the virtual DAS. In step2018, the OEM specific software system 252 electronically receivesmodifications to zone information settings of the virtual DAS. In step2020, the OEM specific software system 252 electronically receivesmodifications to adjustment settings of the virtual DAS, and the process2000 ends.

FIGS. 21-25 are exemplary pages of a user interface of the OEM specificsoftware system 252 for configuring a new profile (as similarlydescribed in FIG. 20). More specifically, FIG. 21 is an exemplary siteconfiguration page 2100 provided by the OEM specific software system 252of the HEU 208 of the real DAS 200 of FIGS. 2 and 3 illustrating siteconfiguration settings for a site configuration phase. As shown, thesite configuration page 2100 comprises a number of configuration phaseswith status indicators. For example, in certain embodiments, theconfiguration phases comprise a site configuration phase 2102, anamplifier sharing phase 2104, an antenna configuration phase 2106, arun-time options phase 2108, a zone information phase 2110, anadjustment phase 2112, etc.

The configuration phase 2102 enables a user to configure site specificparameters. The amplifier sharing phase 2104 enables the user toallocate different percentages of amplification for same band RIMs. Theantenna configuration phase 2106 enables a user to select the antennasource type (e.g., internal, external) for each of the installed modules(e.g., RAU/RAU5 units). The run-time options phase 2108 enables a userto expand and/or replace modules. The zone information phase 2110enables a user to label each unit in the system to help classify andlocate the different units (e.g., Building 1; Floor 1; Room 1). Theadjustment phase 2112 enables a user to perform the adjustment procedurefor uplink and downlink gains of the RIMs and OIMs, as well as to adjustthe target output power of the services transmitted by the remote-endunits.

In certain embodiments, the status indicator indicates to a user whethera particular phase is currently being configured (e.g., red as shown inthe site configuration phase 2102), is completed (e.g., green as shownin the amplifier sharing phase 2104), or has not yet been performed(e.g., transparent as shown in the antenna configuration phase 2106, therun-time options phase 2108, the zone information phase 2110, and theadjustment phase 2112).

The site configuration page 2100 further includes a select service groupdrop down menu 2114 enabling a user to select a particular service group(as discussed in FIGS. 4 and 5). The site configuration page 2100 alsoincludes a first site icon 2116 with a first site status indicator 2118,a second site icon 2120 with a second site status indicator 2122, and aconnection indicator 2124 illustrating the status of the connectionbetween the first site and the second site. A user can accessconfiguration options for each of these sites (e.g., by clicking on thefirst site icon 2116 or the second site icon 2120).

FIG. 22 is an exemplary site configuration page 2200 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating a module owner subphase of the site configurationphase. More specifically, the site configuration page 2200 provides amodule owner subphase 2202 (with a first module owner status indicator2210A and/or a second first module owner status indicator 2212A), a MIMOsetup subphase 2204 (with a first module owner status indicator 2210Band/or a second first module owner status indicator 2212B), an RF pathsubphase 2206 (with a first module owner status indicator 2210C and/or asecond first module owner status indicator 2212C), and/or a max inputsubphase 2208 (with a first module owner status indicator 2210D and/or asecond first module owner status indicator 2212D).

The site configuration page 2200 could also include a first HEU chassis2214 (with one or more modules 2220A-2220D), a second HEU chassis 2216(with one or more modules 2222A-2222D), and/or a third HEU chassis 2218(with one or more modules 2224A-2224C). Further, the site configurationpage provides a carrier selection drop down menu 2226 requesting a userto select from one of a plurality of carriers (e.g., all, carrier 1,carrier 2, carrier 3, carrier 4, etc.). This enables a user to assignservice specific RIM modules to one or more groups (e.g., correspondingto operators). The module owner subphase displays all connected HEUsand/or IHUs in a device view area. Unconfigured and unassigned RIMmodules appear gray. All modules could be assigned to all groups or tospecific groups (where groups include operators, carriers, etc.). Bluecheckmarks could be applied to modules to indicate which modules areconfigured.

FIG. 23 is an exemplary site configuration page 2300 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating a MIMO setup subphase of the site configurationphase. The MIMO setup sub-phase enables a user to configure the modules(e.g., RIM modules) for the MIMO paths.

As shown in FIG. 23, the site configuration page 2300 could include afirst HEU chassis 2302 (with a plurality of modules 2306A-2306E) and asecond HEU chassis 2304 (with a plurality of modules 2308A-2308E). Eachof the modules could have one or more status indicators to indicate to auser the status of the modules. For example, each of the modules couldinclude a first colored status indicator and/or a second statusindicator. The first colored status indicator could include green (e.g.,to indicate a selected module), gray (e.g., to indicate a not selectedmodule), and/or transparent (e.g., to indicate a disabled ordisconnected module). The second status indicator could be a checkmark(e.g., a blue checkmark) to indicate if a module has been assigned andconfigured.

A user can select a first module (e.g., RIM-M module 2306E) in the firstchassis 2302, and a second module (e.g., RIM module 2308E) in the secondchassis 2304, and then indicate whether the two modules should bedisconnected (e.g., by clicking a UPAIR button 2310) or connected (e.g.,by clicking a PAIR button 2312). In this way, for example, the user canconnect pairs of RIM-M and RIM modules supporting the same band (e.g.,AWS) which will then be extended to the corresponding remote unit (e.g.,via the OIM). The OEM specific software system 252 can guide a userthrough connecting modules. For example, modules that are available forpairing can be identified to a user. When the RIM-M module 2306E in thefirst chassis 2302 is selected, the compatible RIM modules in the secondchassis 2304 will appear gray (e.g., RIM module 2308E), and incompatibleor unavailable modules will appear transparent (e.g., RIM modules2308A-2308D).

FIG. 24 is an exemplary site configuration page 2400 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating RF path configuration setup subphase of the siteconfiguration phase (as discussed in FIGS. 4 and 5). The OEM specificsoftware system 252 enables configuration of user controlled servicegroups, where each service group could be transferred to a specifiedremote site. As shown, the site configuration page 2400 provides aservice group drop down menu 2402, and service group identifiers 2406A,2406B, 2406C, displaying to a user which service group has beenselected. Further, a module legend 2404 is provided that indicateswhether a module is selectable, selected, and/or disabled, as shown inthe first HEU chassis 2408A (with a plurality of first chassis modules2410A), a second HEU chassis 2408B (with a plurality of first chassismodules 2410B), a third HEU chassis 2408C (with a plurality of firstchassis modules 2410C), a first OIU chassis 2412A (with a plurality offirst chassis modules 2414A), a second OIU chassis 2412B (with aplurality of first chassis modules 2414B), and a third OIU chassis 2412C(with a plurality of first chassis modules 2414C).

This arrangement could be used where different combinations of servicesare distributed at various locations on the same floor of a buildingaccording to coverage requirements. The RF path configuration setupsubphase determines the services distributed at the remote site. Notethat each RIM can be configured for all service groups, and each RIM canbe assigned to each OIM in a service group. The OEM specific softwaresystem 252 could be configured such that selecting a RIM-M moduleautomatically selects the connected RIM module as well, and configuresthe RIM module for the same service group.

FIG. 25 is an exemplary site configuration page 2500 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating a max-input configuration setup subphase of thesite configuration phase. The max-input configuration setup subphase isused to set the DL maximum expected power (e.g., −10 to 37 dBm) for eachRIM and the UL gain. The configured max expected power determines themaximum UL gain range enabled for configuration. As shown, the siteconfiguration page 2500 includes a first chassis 2502 with a pluralityof first chassis modules 2504, and a second chassis 2506 with aplurality of second chassis modules 2508. The exemplary siteconfiguration page 2500 provides a plurality of drop down menus and/orfields for configuration of the max-input. More specifically, a selectgroup drop down menu 2510, a select chassis drop down menu 2512, aselect band drop down menu 2514, a set max expected power drop down menu2516, a select UL gain mode drop down menu 2518 (e.g., manual,asymmetrical, etc.), a select UL gain value drop down menu 2520 (e.g.,−28 dB to +15 dB). Here, and at other steps throughout, the OEM specificsoftware system 252 enforces upon the profile OEM design constraints ofreal settings of equipment in the real DAS.

FIG. 26 is an exemplary site configuration page 2600 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating a selected layer for a link RF path of the siteconfiguration phase. More specifically, the site configuration page 2600includes a first site RIM list 2602 and a second site OIM list 2604.This enables the user to select service groups to be distributed betweenthe linked sites and open the RF path for the link (e.g., for campusconnectivity topologies with FMM-FRM modules.

FIG. 27 is an exemplary site configuration page 2700 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating amplifier sharing settings of an amplifier settingphase. More specifically, the site configuration page 2700 comprises aselect band drop down menu 2702 (e.g., CELL/ESMR) and a select servicegroup drop down menu 2704 (e.g., SG-1 SITE-13). The site configurationpage 2700 further includes a carrier-select section 2706 andRIM/DIM-select section 2708. The carrier-select section 2706 enables auser to allocate by carrier or group. For example, a carrier-selecttotal amplifier sharing sliding bar 2710 enables a user to adjust thepercentage of amplifier sharing (e.g., 26.5%), and a carrier-selectamplifier sharing between carriers sliding bar 2712 enables a user toadjust the percentage of amplifier sharing between carriers (e.g., 37.5%for Carrier 1 and 36% for Carrier 2). The RIM/DIM-select section 2708enables a user to allocate by RIM. For example, a RIM/DIM-select totalamplifier sharing sliding bar 2714 enables a user to adjust thepercentage of amplifier sharing (e.g., 26.5%), and a RIM/DIM-selectamplifier sharing between RIMs/DIMs sliding bar 2716 enables a user toadjust the percentage of amplifier sharing between RIMs/DIMs (e.g.,37.5% for Carrier 1 RIM and 36% for Carrier 2 RIM).

FIGS. 28-35 are exemplary site management pages provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 enabling a user to monitor, manage, and control campuses,connected sites, system elements, etc. More specifically, FIG. 28 is anexemplary site management page 2800 provided by the OEM specificsoftware system 252 of the HEU 208 of the real DAS 200 of FIGS. 2 and 3illustrating a campus view for site management. The site management page2800 could be accessible through the management tab 1002.

The site management page 2800 comprises a network topology tree 2802which hierarchically displays the connected and available system devicesand their status. The network topology tree 2802 could include statuscolors to indicate the status of each detected element (e.g., greenrepresents OK, yellow represents a minor error, red represents a majorerror, gray represents no communication to a device set in base line,etc.). The DAS elements could comprise head-end units (e.g., HEU, OIU,IHU, etc.) and other elements (e.g., ACMs, RIMs, OIMs, RAUs, etc.) persite. In certain embodiments, the OEM specific software system 252enables a user to specify the type of site (e.g., airport, highbuilding, stadium, hospital, resident building, mall, campus, parking,hotel, etc.).

The site management page 2800 further comprises a campus view 2804graphically displaying the sites (e.g., represented by icons indicatingthe overall status of each). The site management page 2800 furthercomprises a select service group drop down menu 2806, a device alarmssection 2808, and a module info tab 2810, and a comment tab 2812. Morespecifically, the device alarms section 2808 comprises informationcorresponding to fault sourcing and provides alarm masking options(e.g., HW failure, adjustment failure, installation failure, SW releasemismatch, connectivity, etc.). The module info tab 2810 provides devicespecific information, such as configurable parameters (e.g., servicecontrol, RF parameters) and/or general information (e.g., device name,firmware version, reset option, etc.). The comment tab 2812 enables auser to provide additional comments for a particular component selected.

FIG. 29 is an exemplary site management page 2900 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating a site view for site management. More specifically,the site management page 2900 provides a view mode status bar 2902indicating view mode information (e.g., Site-5 Site View Mode), as wellas a first view button 2904 (e.g., to toggle between campus view andsite view) and a second view button 2906 (e.g., to toggle between siteview and rack view). More specifically, campus view graphically displaysthe sites which are represented by icons indicating the overall statusof each site. The site view provides visualization of the selecteddevice, with LEDs corresponding to the device status. The rack viewprovides a graphical display of all head-end elements which reflect thephysical head-end rack installation on-site. The order of the chassiscould be rearranged to reflect the physical installation of the chassisin the communication rack. The site management page further comprises asite alarm section 2912 providing site alarm information (e.g.,adjustment failure, SW release mismatch, connectivity, overall status,etc.) and site info section 2914 providing site information (e.g., sitename, site location, site type, etc.).

FIG. 30 is an exemplary site management page 3000 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating a rack view for site management. As shown, the sitemanagement page 3000 provides a rack view including a campus view button3002, a device view button 3004, and an edit rack button 3006). Furtherthe site management page 3000 comprises a first edit rack name button3008A to edit HEU rack names, a second edit rack name button 3008B toedit OIU rack names, a first edit rack button 3010A to edit HEU rackparameters, a second edit rack button 3010B to edit OIU rack parameters,a first identify button 3012A to identify all chassis in a HEU rack, anda second identify button 3012B to identify all chassis in an OIU rack.The site management page 3000 enables a user to add racks (e.g.,including rack size) and add devices. Further, the rack view allowsplaceholder views for passive devices (e.g., ICU, Six-channel poweramplifier unit (PAU6), fiber management unit (FMU) and custom unit).

FIG. 31 is an exemplary site management page 3100 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating PAM alarms and alarm configurations. The sitemanagement page 3100 includes a HEU chassis 3106 with a plurality of HEUmodules 3107, and an OIU chassis 3108 with a plurality of OIU modules3109. Further, the site management page 3100 shows an MRU device 3110and a remote device 3112. The remote device 3112 includes a plurality oficons, including an RxU module icon 3114 (e.g., representing aninstalled RxU module), a GEM module icon 3118 (e.g., representing aninstalled GEM module), and/or an overall status LED 3116.

The site management page 3100 includes an alarms history section 3120(e.g., inconsistent version, over temperature, service 700, serviceCELL/ESMR, service AWS, service PCS, service WCS, adjustment fault, hwfailure, overall status, etc.). The site management page furtherincludes a module info tab 3122 (provides device version andidentification definitions), a PAM alarms tab 3124 (displays specificalarms for each supported device), an alarms tab 3126 (displays devicealarms, such as module specific alarms for fault sourcing), an RFparameters tab 3128 (includes configurable RF parameters (e.g., RIMgain, RAU output power, etc.) relevant to the selected device, and acomments tab 3130 (for entering additional information relevant to theselected device). The content of the alarms history section 3120, moduleinfo tab 3122, PAM alarms tab 3124, alarms tab 3126, RF parameters tab3128, and comments tab 3130 varies depending on the DAS element selected(e.g., OIU, HEU, RAU, etc.). The alarms ensure that the real DAS isperforming as the virtual DAS intended. If a problem is identified, theOEM specific software system identifies the source of the potentialproblem and guides a user through fixing the problem.

For an HCM module, the OEM specific software system 252 can alert a user(and help troubleshoot) as to the following device alarms: HW failure(indicates HCM faulty hardware), adjustment failure (indicatesunsuccessful adjustment procedure), installation failure (indicatesfaulty physical connection between chassis), SW release mismatch(indicates that a module(s) in the system does not have the definedactive release), connectivity (indicates faulty connectivity state inone of the (baseline) system modules), and overall status (indicatesoverall status of enabled (unmasked) alarms), etc.

For a site, the system can alert a user (and help troubleshoot) as tothe following device alarms: adjustment failure (indicates unsuccessfuladjustment procedure for a module(s) in the selected site), SW releasemismatch (indicates module(s) in the selected site have been detectedwith mismatched software versions), connectivity (indicates disconnectedmodules have been detected in the site), and overall status (indicatesoverall status of enabled (unmasked) alarms), etc.

For an ACM, the OEM specific software system 252 can alert a user (andhelp troubleshoot) as to the following device alarms: inconsistentversion (indicates that the module does not have the defined activerelease), over temperature (indicates ambient temperature inside the ACMis greater than a predefined threshold temperature (e.g., >75° C.)), HWfailure (indicates faulty HW upon initialization or during operation),adjustment fault (indicates unsuccessful adjustment procedure for theselected module), power failure (indicates a power failure oroverheating in one or more of the PSM (power supply module)), fanfailure (indicates a fault in at least one of the fans in the fanmodule), Ext1/Ext2 Clock Failed (indicates failure in master referenceclock in HEU and/or IHU units), pilot clock failed (indicates failure inreference in the pilot clock in the OIX expander for IHU and/or OIU),and Overall Status (indicates overall status of enabled (unmasked)alarms), etc.

For an ACM, the OEM specific software system 252 can also alert a user(and help troubleshoot) as to the following power alarms: temperature(indicates that the temperature of one or more of the PSM modules isgreater than a predefined threshold (e.g., >+70° C.)), output undervoltage (indicates that the ACM has detected an input voltage value lessthan a predefined threshold (e.g., <10.8V DC) from one or more of thePSM modules), and input under voltage (indicates that the ACM hasdetected an input voltage value below a predefined threshold (e.g., <60VAC) from one or more of the PSM modules), etc.

For a RIM, the OEM specific software system 252 can alert a user (andhelp troubleshoot) as to the following device alarms: inconsistentversions (indicates that the module does not have the defined activerelease), DL input power low (indicates that the BTS RF power input tothe RIM is below a predefined threshold (e.g., at least 15 dB lower thanthe configured max expected power)), DL power overload (indicates thatthe BTS RF power input to the RIM is over a predefined threshold (e.g.,at least 3 dB higher than the value measured during the adjustmentprocedure)), service OFF (indicates that service has been disabled),output power, over temperature (indicates ambient temperature inside theRIM is above a predefined threshold (e.g., >75° C.)), adjustment fault(unsuccessful adjustment procedure for the selected module), HW failure(indicates hardware problem during startup or during normal operation),overall clock alarms (indicates that at least one of the RIM-M clockalarms is set), and overall status (indicates overall status of enabled(unmasked) alarms), etc.

For a RIM, the OEM specific software system 252 can also alert a user(and help troubleshoot) as to the following clock alarms: UL synthesizerunlocked (indicates unlocked state of UL synthesizer), DL synthesizerunlocked (indicates unlocked state of DL synthesizer), and referenceclock unlocked (indicates unlocked state of reference clock), etc.

For an OIM, the OEM specific software system 252 can alert a user (andhelp troubleshoot) as to the following device alarms: inconsistentversion (indicates that the module does not have the defined activerelease), optical power low (indicates optical link power (PDI) is <0dBm), over temperature (indicates that the ambient temperature in theOIM is over a predefined threshold (e.g., ≧75° C.)), adjustment fault(indicates unsuccessful adjustment procedure for the selected module),HW failure (indicates hardware problem during startup or during normaloperation), and overall status (indicates overall status of enabled(unmasked) alarms), etc.

For a FMM/FRM, the OEM specific software system 252 can alert a user(and help troubleshoot) as to the following device alarms: inconsistentversion (indicates that the module does not have the defined activerelease), optical power low (indicates that the optical power is below apredefined threshold (e.g., <−10.5 dBm)) MNG optical power low(indicates that the SFP Rx power is below a predefined threshold (e.g.,<−34 dBm)), over temperature (indicates that the ambient temperature inthe FMM/FRM is above a predefined threshold (e.g., >75° C.)), adjustmentfault (indicates unsuccessful adjustment procedure for the selectedmodule), HW failure (indicates HW problem during startup or duringnormal operation), and overall status (indicates overall status ofenabled (unmasked) alarms), etc.

For a RAU, the OEM specific software system 252 can alert a user (andhelp troubleshoot) as to the following device alarms: inconsistentversion (indicates that the module does not have the defined activerelease), over temperature (indicates that the ambient temperature inthe RAU is above a predefined threshold (e.g., >75° C.)), service(indicates that service (e.g. LTE, CELL, etc.) has been disabled byuser), adjustment fault (indicates unsuccessful adjustment procedure forthe selected module), HW failure (indicates hardware problem duringstartup or during normal operation), and overall status (indicatesoverall status of enabled (unmasked) alarms), etc.

For RAU, the OEM specific software system 252 can also alert a user (andhelp troubleshoot) as to the following service alarms: DL out pwr low(indicates that the RF signal power is below a predefined threshold(e.g., ≦15 dB below the configured power level), UL in pwr high(indicates that the RF signal power is greater than required maximumexpected power), and service off (indicates that service has beendisabled by user), etc.

For a RXU, the OEM specific software system 252 can alert a user (andhelp troubleshoot) as to the following device alarms: inconsistentversion (indicates that the module does not have the defined activerelease), over temperature (indicates that the ambient temperature inthe RXU is above a predefined threshold (e.g., ≧75° C.)), ServiceLTE_MIMO/AWS_MIMO (indicates service disabled by user), adjustment fault(indicates unsuccessful adjustment procedure for the selected module),HW failure (indicates hardware problem during startup or during normaloperation), synthesizer clock (indicates unlocked synthesizer clock),and overall status (indicates overall status of enabled (unmasked)alarms), etc.

For a RXU, the OEM specific software system 252 can also alert a user(and help troubleshoot) as to the following service alarms: DL out pwrlow (indicates that the RF signal power is below a predefined threshold(e.g., ≦15 dB below the configured power level)), UL in pwr high(indicates that the RF signal power is greater than required maximumexpected power), service off (indicates that service has been disabledby user), synthesizer DL (indicates that DL synthesizer state isdetected as “unlocked”), and synthesizer UL (indicates that ULsynthesizer state is detected as “unlocked”), etc.

For a MRU, the OEM specific software system 252 can alert a user (andhelp troubleshoot) as to the following MRU alarms: inconsistent version(indicates that the device does not have the defined active release),over temperature (indicates that the ambient temperature in the MRU isabove a predetermined threshold (e.g., >65° C.)), service (indicatesthat service (e.g., 700, CELL, etc.) has been disabled by user),adjustment fault (indicates unsuccessful adjustment procedure for theselected module), HW failure (indicates a hardware component problem(including FAMs) during startup or during normal operation), and overallstatus (indicates overall status of enabled (unmasked) alarms), etc.

For a MRU, the OEM specific software system 252 can also alert a user asto the following PAM alarms: DL out pwr low (indicates that the RFsignal power is less than a predefined threshold (e.g., ≦15 dB below theconfigured power level)), UL in pwr high (indicates that the RF signalpower is greater than expected UL power and cannot be limited due tolimiter reaching full capacity), service off (indicates that service hasbeen disabled by user), VSWR (indicates that the PAM has reported a VSWRproblem), shut down (indicates power amplifier module shut down),permanent shut down (indicates that 10 shut downs have occurred duringthe last 100 minutes), over temperature (indicates that the ambienttemperature of the power amplifier modules is above a predeterminedthreshold (e.g., >65° C.)), out of slot (indicates that the PAM has beenextracted from the slot), and over power (indicates that PA output powerhas exceeded maximum threshold (thresholds depends on band)), etc.

For a MRU, the OEM specific software system 252 could also alert a useras to the following additional alarms: door open (indicates that the MRUchassis door is open), fan velocity (indicates that the fan velocity isbelow the minimum threshold determined by the controller), overtemperature when door open (indicates that the door has been open (e.g.,for over 5 seconds) and that one of the PA modules is below the shutdown limit temperature (e.g., 4° C. below the shut down limit)), powersupply problem (indicates detected problem in power supply), low opticalpower (indicates that the detected optical power is lower than theconfigured threshold), OPTM-S over temperature alarm, cabinet door alarm(indicates that the door of the outdoor enclosure is open), and heatexchanger failure (indicates failure in the heat exchange unit of theoutdoor enclosure), etc.

FIG. 32 is an exemplary site management page 3200 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating RF parameter configurations. Similar to the sitemanagement page 3100 of FIG. 31, site management page 3200 of FIG. 32includes an alarms history section 3220, module info tab 3222, alarmstab 3226, RF parameters tab 3228, and comments tab 3230. As mentionedabove, a user could configure RF parameters for RIM/RIM-M modules (e.g.,max expected power, UL gain mode, UL gain, DL power detector, automaticlimit control, service state, temperature, etc.). A user could alsoconfigure RF parameters for an OIM module (e.g., DL power state, outpower, UL limiter, ext. filters, antenna source). A user could alsoconfigure RF parameters for an RXU module (e.g., DL power, state, ULlimiter, ext. filter, antenna source, etc.). A user could also configureRF parameters for an MRU (e.g., DL power state, out power, UL limiter,etc.). Each of these RF parameters could be configured for each of oneor more bands (e.g., 700, CELL, PCS, AWS, CELL/ESMR, etc.). As alsomentioned above, the OEM specific software system 252 electronicallyenforces upon the RF parameters (virtual DAS setting) OEM designconstraints of real setting(s) of equipment in the real DAS 200.

FIGS. 33-35 are exemplary pages provided by the OEM specific softwaresystem 252 of the HEU 208 of the real DAS 200 of FIGS. 2 and 3illustrating use of location maps. The location maps are used to displaygeographical location information of configured sites and graphicallydisplay their floor plans. Remote units can be assigned to floors ofbuildings and then placed within the floors to provide a view of theactual layout and coverage of the installed DAS system throughout thedifferent floors.

More specifically, FIG. 33 is an exemplary site management page 3300provided by the OEM specific software system 252 of the HEU 208 of thereal DAS 200 of FIGS. 2 and 3 illustrating a location map for displayinggeographical location information for configured sites of a virtual DAS.The site management page 3300 comprises an add building button 3302 andan add floor button 3304. The add building button 3302 adds a building(e.g., first building 3308, second building 3310, etc.) to the locationmap 3306 for placement therein. The location of the building 3308, 3310can be moved within the location map 3306 by a user. The add floorbutton 3304 adds one or more floors to one or more of the buildings3308, 3310. The location map can imported into the OEM specific softwaresystem 252 (e.g., from a third party platform or locally from a user'scomputer, etc.).

FIG. 34 is an exemplary site management page 3400 provided by the OEMspecific software system 252 of the HEU 208 of the real DAS 200 of FIGS.2 and 3 illustrating placement of a remote 3404 to a desired location ona floor blueprint 3402 of a building for a virtual DAS. The OEM specificsoftware system 252 enables a user to assign a remote to, and place theremote within, a floor plan of a building. The remote can then be placedanywhere on the floorplan (see FIG. 38), such as by dragging anddropping.

FIG. 35 is an exemplary view of a site management page 3500 provided bythe OEM specific software system 252 of the HEU 208 of the real DAS 200of FIGS. 2 and 3 illustrating module information for a selected remoteof a virtual DAS. By clicking on the remote within the floor plan, thesite management page displays remote information, such as RAU alarmhistory 3502, module information in the module info tab 3504, alarmsinformation in the alarm tab 3506, RF parameter information in the RFtab 3508, and/or comments in the comment tab 3510.

FIG. 36 is a schematic diagram of an exemplary WDCS provided in the formof an exemplary optical fiber-based DAS 3600. The DAS 3600 in thisexample is an optical fiber-based DAS. The DAS 3600 in this example iscomprised of three (3) main components. One or more radio interfacesprovided in the form of radio interface modules (RIMs) 3602(1)-3602(T)are provided in a central unit 3604 to receive and process downlinkelectrical communications signals 3606D(1)-3606D(S) prior to opticalconversion into downlink optical communications signals. The downlinkelectrical communications signals 3606D(1)-3606D(S) may be received froma base station (not shown) as an example. The RIMs 3602(1)-3602(T)provide both downlink and uplink interfaces for signal processing. Thenotations “1-S” and “1-T” indicate that any number of the referencedcomponent, 1-S and 1-T, respectively, may be provided.

With continuing reference to FIG. 36, the central unit 3604 isconfigured to accept the plurality of RIMs 3602(1)-3602(T) as modularcomponents that can easily be installed and removed or replaced in thecentral unit 3604. In one embodiment, the central unit 3604 isconfigured to support up to twelve (12) RIMs 3602(1)-3602(12). Each RIM3602(1)-3602(T) can be designed to support a particular type of radiosource or range of radio sources (i.e., frequencies) to provideflexibility in configuring the central unit 3604 and the DAS 3600 tosupport the desired radio sources. For example, one RIM 3602 may beconfigured to support the Personal Communication Services (PCS) radioband. Another RIM 3602 may be configured to support the 700 MHz radioband. In this example, by inclusion of these RIMs 3602, the central unit3604 could be configured to support and distribute RF communicationssignals, including those for the communications services andcommunications bands described above as examples.

The RIMs 3602(1)-3602(T) may be provided in the central unit 3604 thatsupport any frequencies desired, including but not limited to licensedUS FCC and Industry Canada frequencies (824-849 MHz on uplink and869-894 MHz on downlink), US FCC and Industry Canada frequencies(1850-1915 MHz on uplink and 1930-1995 MHz on downlink), US FCC andIndustry Canada frequencies (1710-1755 MHz on uplink and 2110-2155 MHzon downlink), US FCC frequencies (698-716 MHz and 776-787 MHz on uplinkand 728-746 MHz on downlink), EU R & TTE frequencies (880-915 MHz onuplink and 925-960 MHz on downlink), EU R & TTE frequencies (1710-1785MHz on uplink and 1805-1880 MHz on downlink), EU R & TTE frequencies(1920-1980 MHz on uplink and 2110-2170 MHz on downlink), US FCCfrequencies (806-824 MHz on uplink and 851-869 MHz on downlink), US FCCfrequencies (896-901 MHz on uplink and 929-941 MHz on downlink), US FCCfrequencies (793-805 MHz on uplink and 763-775 MHz on downlink), and USFCC frequencies (2495-2690 MHz on uplink and downlink).

With continuing reference to FIG. 36, the downlink electricalcommunications signals 3606D(1)-3606D(S) may be provided as downlinkelectrical spectrum chunks to a plurality of optical interfaces providedin the form of optical interface modules (OIMs) 3608(1)-3608(W) in thisembodiment to convert the unlicensed and/or licensed downlink electricalcommunications signals 3606D(1)-3606D(S) (“downlink electricalcommunications signals 3606D(1)-3606D(S)”) into downlink opticalspectrum chunks 3610D(1)-3610D(S). The notation “1-W” indicates that anynumber of the referenced component 1-W may be provided. The OIMs 3608may be configured to provide one or more optical interface components(OICs) that contain optical-to-electrical (O-E) andelectrical-to-optical (E-O) converters, as will be described in moredetail below. The OIMs 3608 support the radio bands that can be providedby the RIMs 3602, including the examples previously described above.

The OIMs 3608(1)-3608(W) each include E-O converters to convert thedownlink electrical communications signals 3606D(1)-3606D(S) into thedownlink optical spectrum chunks 3610D(1)-3610D(S). The downlink opticalspectrum chunks 3610D(1)-3610D(S) are communicated over downlink opticalfiber communications medium 3612D to a plurality of remote unitsprovided in the form of RAUs 3614(1)-3614(X). The notation “1-X”indicates that any number of the referenced component 1-X may beprovided. O-E converters provided in the RAUs 3614(1)-3614(X) convertthe downlink optical spectrum chunks 3610D(1)-3610D(S) back into thedownlink electrical communications signals 3606D(1)-3606D(S), which areprovided to antennas 3616(1)-3616(X) in the RAUs 3614(1)-3614(X) to userequipment (not shown) in the reception range of the antennas3616(1)-3616(X).

E-O converters are also provided in the RAUs 3614(1)-3614(X) to convertuplink electrical communications signals 3620U(1)-3620U(X) received fromuser equipment (not shown) through the antennas 3616(1)-3616(X) intouplink optical spectrum chunks 3610U(1)-3610U(X). The RAUs3614(1)-3614(X) communicate the uplink optical spectrum chunks3610U(1)-3610U(X) over an uplink optical fiber communications medium3612U to the OIMs 3608(1)-3608(W) in the central unit 3604. The OIMs3608(1)-3608(W) include O-E converters that convert the received uplinkoptical spectrum chunks 3610U(1)-3610U(X) into uplink electricalcommunications signals 3622U(1)-3622U(X), which are processed by theRIMs 3602(1)-3602(T) and provided as uplink electrical communicationssignals 3622U(1)-3622U(X). The central unit 3604 may provide the uplinkelectrical communications signals 3622U(1)-3622U(X) to a sourcetransceiver such as a base station or other communications system.

Note that the downlink optical fiber communications medium 3612D anduplink optical fiber communications medium 3612U connected to each RAU3614(1)-3614(X) may be a common optical fiber communications medium,wherein for example, wave division multiplexing (WDM) may be employed toprovide the downlink optical spectrum chunks 3610D(1)-3610D(S) and theuplink optical spectrum chunks 3610U(1)-3610U(X) on the same opticalfiber communications medium.

FIG. 37 is a partially schematic cut-away diagram of an exemplary indoorenvironment (e.g., building infrastructure) in which a WDCS can beprovided. In this regard, FIG. 37 is a partially schematic cut-awaydiagram of a building infrastructure 3700 employing a WDCS 3702employing a programmable digital signal processing circuit for scalingsupported communications services. The building infrastructure 3700 inthis embodiment includes a first (ground) floor 3704(1), a second floor3704(2), and a third floor 3704(3). The floors 3704(1)-3704(3) areserviced by the central unit 3706 to provide the antenna coverage areas3708 in the building infrastructure 3700. The central unit 3706 iscommunicatively coupled to a base station 3709 to receive downlinkcommunications signals 3714D from the base station 3709. The basestation 3709 may be coupled to an operational and support system (OSS)3710 to receive data about the performance of RAUs 3712 in the WDCS 3702on a per remote unit basis for determining WDCS optimizations. Thecentral unit 3706 is communicatively coupled to the RAUs 3712 to receiveuplink communications signals 3714U from the RAUs 3712, similar to aspreviously discussed above for other WDCSs. The central unit 3706 may beconfigured to employ spectrum chunk construction for construction ofspectrum chunks from individually received communications channels fordistribution to RAUs 3712. The downlink and uplink communicationssignals 3714D, 3714U communicated between the central unit 3706 and theRAUs 3712 are carried over a riser cable 3716 in this example. The risercable 3716 may be routed through interconnect units (ICUs)3718(1)-3718(3) dedicated to each floor 3704(1)-3704(3) that route thedownlink and uplink communications signals 3714D, 3714U to the RAUs 3712and also provide power to the RAUs 3712 via array cables3720(1)-3720(6).

FIG. 38 is a schematic diagram of a generalized representation of anexemplary computer system 3800 that can be included in any component ina WDCS and/or DAS. In this regard, the computer system 3800 is adaptedto execute instructions from an exemplary computer-readable medium toperform these and/or any of the functions or processing describedherein.

In this regard, the computer system 3800 in FIG. 38 may include a set ofinstructions that may be executed to program and configure programmabledigital signal processing circuits in a WDCS for supporting scaling ofsupported communications services. The computer system 3800 may beconnected (e.g., networked) to other machines in a LAN, an intranet, anextranet, or the Internet. While only a single device is illustrated,the term “device” shall also be taken to include any collection ofdevices that individually or jointly execute a set (or multiple sets) ofinstructions to perform any one or more of the methodologies discussedherein. The computer system 3800 may be a circuit or circuits includedin an electronic board card, such as a printed circuit board (PCB), aserver, a personal computer, a desktop computer, a laptop computer, apersonal digital assistant (PDA), a computing pad, a mobile device, orany other device, and may represent, for example, a server or a user'scomputer.

The exemplary computer system 3800 in this embodiment includes aprocessing device or processor 3802, a main memory 3804 (e.g., read-onlymemory (ROM), flash memory, dynamic random access memory (DRAM), such assynchronous DRAM (SDRAM), etc.), and a static memory 3806 (e.g., flashmemory, static random access memory (SRAM), etc.), which may communicatewith each other via a data bus 3808. Alternatively, the processor 3802may be connected to the main memory 3804 and/or static memory 3806directly or via some other connectivity means. The processor 3802 may bea controller, and the main memory 3804 or static memory 3806 may be anytype of memory.

The processor 3802 represents one or more general-purpose processingdevices, such as a microprocessor, central processing unit, or the like.More particularly, the processor 3802 may be a complex instruction setcomputing (CISC) microprocessor, a reduced instruction set computing(RISC) microprocessor, a very long instruction word (VLIW)microprocessor, a processor implementing other instruction sets, orother processors implementing a combination of instruction sets. Theprocessor 3802 is configured to execute processing logic in instructionsfor performing the operations and steps discussed herein.

The computer system 3800 may further include a network interface device3810. The computer system 3800 also may or may not include an input3812, configured to receive input and selections to be communicated tothe computer system 3800 when executing instructions. The computersystem 3800 also may or may not include an output 3814, including butnot limited to a display, a video display unit (e.g., a liquid crystaldisplay (LCD) or a cathode ray tube (CRT)), an alphanumeric input device(e.g., a keyboard), and/or a cursor control device (e.g., a mouse).

The computer system 3800 may or may not include a data storage devicethat includes instructions 3816 stored in a computer-readable medium3818. The instructions 3816 may also reside, completely or at leastpartially, within the main memory 3804 and/or within the processor 3802during execution thereof by the computer system 3800, the main memory3804 and the processor 3802 also constituting computer-readable medium.The instructions 3816 may further be transmitted or received over anetwork 3820 via the network interface device 3810.

While the computer-readable medium 3818 is shown in an exemplaryembodiment to be a single medium, the term “computer-readable medium”should be taken to include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more sets of instructions. The term“computer-readable medium” shall also be taken to include any mediumthat is capable of storing, encoding, or carrying a set of instructionsfor execution by the processing device and that cause the processingdevice to perform any one or more of the methodologies of theembodiments disclosed herein. The term “computer-readable medium” shallaccordingly be taken to include, but not be limited to, solid-statememories, optical medium, and magnetic medium.

The embodiments disclosed herein include various steps. The steps of theembodiments disclosed herein may be formed by hardware components or maybe embodied in machine-executable instructions, which may be used tocause a general-purpose or special-purpose processor programmed with theinstructions to perform the steps. Alternatively, the steps may beperformed by a combination of hardware and software.

The embodiments disclosed herein may be provided as a computer programproduct, or software, that may include a machine-readable medium (orcomputer-readable medium) having stored thereon instructions, which maybe used to program a computer system (or other electronic devices) toperform a process according to the embodiments disclosed herein. Amachine-readable medium includes any mechanism for storing ortransmitting information in a form readable by a machine (e.g., acomputer). For example, a machine-readable medium includes: amachine-readable storage medium (e.g., ROM, random access memory(“RAM”), a magnetic disk storage medium, an optical storage medium,flash memory devices, etc.); and the like.

Unless specifically stated otherwise and as apparent from the previousdiscussion, it is appreciated that throughout the description,discussions utilizing terms such as “processing,” “computing,”“determining,” “displaying,” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data and memories represented asphysical (electronic) quantities within the computer system's registersinto other data similarly represented as physical quantities within thecomputer system memories or registers or other such information storage,transmission, or display devices.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various systems may beused with programs in accordance with the teachings herein, or it mayprove convenient to construct more specialized apparatuses to performthe required method steps. The required structure for a variety of thesesystems will appear from the description above. In addition, theembodiments described herein are not described with reference to anyparticular programming language. It will be appreciated that a varietyof programming languages may be used to implement the teachings of theembodiments as described herein.

Those of skill in the art will further appreciate that the variousillustrative logical blocks, modules, circuits, and algorithms describedin connection with the embodiments disclosed herein may be implementedas electronic hardware, instructions stored in memory or in anothercomputer-readable medium and executed by a processor or other processingdevice, or combinations of both. The components of the distributedantenna systems described herein may be employed in any circuit,hardware component, integrated circuit (IC), or IC chip, as examples.Memory disclosed herein may be any type and size of memory and may beconfigured to store any type of information desired. To clearlyillustrate this interchangeability, various illustrative components,blocks, modules, circuits, and steps have been described above generallyin terms of their functionality. How such functionality is implementeddepends on the particular application, design choices, and/or designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the presentembodiments.

The various illustrative logical blocks, modules, and circuits describedin connection with the embodiments disclosed herein may be implementedor performed with a processor, a Digital Signal Processor (DSP), anApplication Specific Integrated Circuit (ASIC), a Field ProgrammableGate Array (FPGA), or other programmable logic device, a discrete gateor transistor logic, discrete hardware components, or any combinationthereof designed to perform the functions described herein. Furthermore,a controller may be a processor. A processor may be a microprocessor,but in the alternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices (e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration).

The embodiments disclosed herein may be embodied in hardware and ininstructions that are stored in hardware, and may reside, for example,in RAM, flash memory, ROM, Electrically Programmable ROM (EPROM),Electrically Erasable Programmable ROM (EEPROM), registers, a hard disk,a removable disk, a CD-ROM, or any other form of computer-readablemedium known in the art. An exemplary storage medium is coupled to theprocessor such that the processor can read information from, and writeinformation to, the storage medium. In the alternative, the storagemedium may be integral to the processor. The processor and the storagemedium may reside in an ASIC. The ASIC may reside in a remote station.In the alternative, the processor and the storage medium may reside asdiscrete components in a remote station, base station, or server.

It is also noted that the operational steps described in any of theexemplary embodiments herein are described to provide examples anddiscussion. The operations described may be performed in numerousdifferent sequences other than the illustrated sequences. Furthermore,operations described in a single operational step may actually beperformed in a number of different steps. Additionally, one or moreoperational steps discussed in the exemplary embodiments may becombined. Those of skill in the art will also understand thatinformation and signals may be represented using any of a variety oftechnologies and techniques. For example, data, instructions, commands,information, signals, bits, symbols, and chips, that may be referencesthroughout the above description, may be represented by voltages,currents, electromagnetic waves, magnetic fields, or particles, opticalfields or particles, or any combination thereof.

Unless otherwise expressly stated, it is in no way intended that anymethod set forth herein be construed as requiring that its steps beperformed in a specific order. Accordingly, where a method claim doesnot actually recite an order to be followed by its steps, or it is nototherwise specifically stated in the claims or descriptions that thesteps are to be limited to a specific order, it is in no way intendedthat any particular order be inferred.

It will be apparent to those skilled in the art that variousmodifications and variations can be made without departing from thespirit or scope of the invention.

Further, as used herein, it is intended that terms “fiber optic cables”and/or “optical fibers” include all types of single mode and multi-modelight waveguides, including one or more optical fibers that may beupcoated, colored, buffered, ribbonized and/or have other organizing orprotective structure in a cable such as one or more tubes, strengthmembers, jackets or the like. Likewise, other types of suitable opticalfibers include bend-insensitive optical fibers, or any other expedientof a medium for transmitting light signals. An example of abend-insensitive, or bend resistant, optical fiber is ClearCurve®Multimode fiber commercially available from Corning Incorporated.Suitable fibers of this type are disclosed, for example, in U.S. PatentApplication Publication Nos. 2008/0166094 and 2009/0169163.

Many modifications and other embodiments of the embodiments set forthherein will come to mind to one skilled in the art to which theembodiments pertain having the benefit of the teachings presented in theforegoing descriptions and the associated drawings. Therefore, it is tobe understood that the description and claims are not to be limited tothe specific embodiments disclosed and that modifications and otherembodiments are intended to be included within the scope of the appendedclaims. It is intended that the embodiments cover the modifications andvariations of the embodiments provided they come within the scope of theappended claims and their equivalents. Although specific terms areemployed herein, they are used in a generic and descriptive sense onlyand not for purposes of limitation.

What is claimed is:
 1. A non-transitory computer readable mediumcomprising program instructions for implementing a live wirelesscommunication system configuration from a virtual wireless communicationsystem design using an original equipment manufacturer (OEM) specificsoftware system in a real wireless communication system, the programinstructions, when executed, comprising: configuring, by an OEM specificsoftware system in a real wireless communication system, at least onevirtual wireless communication system setting for a virtual wirelesscommunication system; enforcing, by the OEM specific software system,upon the at least one virtual wireless communication system setting OEMdesign constraints of at least one real setting of signal distributionequipment in the real wireless communication system; generating, by theOEM specific software system, at least one virtual wirelesscommunication system configuration file comprising the at least onevirtual wireless communication system setting for the virtual wirelesscommunication system; storing, by the OEM specific software system, theat least one virtual wireless communication system configuration file inmemory at the real wireless communication system; and modifying, by theOEM specific software system, the at least one real setting of thesignal distribution equipment in the real wireless communication systembased on the at least one virtual wireless communication system settingin the at least one virtual wireless communication system configurationfile.
 2. The non-transitory computer readable medium of claim 1, whereinconfiguring, by the OEM specific software system in the real wirelesscommunication system, at least one virtual wireless communication systemsetting for a virtual wireless communication system comprises creatingthe at least one virtual wireless communication system setting for thevirtual wireless communication system.
 3. The non-transitory computerreadable medium of claim 2, wherein configuring, by the OEM specificsoftware system in the real wireless communication system, the at leastone virtual wireless communication system setting for the virtualwireless communication system comprises importing the at least onevirtual wireless communication system setting for the virtual wirelesscommunication system.
 4. The non-transitory computer readable medium ofclaim 2, wherein configuring, by the OEM specific software system in thereal wireless communication system, the at least one virtual wirelesscommunication system setting for the virtual wireless communicationsystem comprises modifying the at least one virtual wirelesscommunication system setting for the virtual wireless communicationsystem.
 5. The non-transitory computer readable medium of claim 2,wherein the at least one real setting of the signal distributionequipment in the real wireless communication system comprises at leastone of an RF path configuration, power amplifier setting, attenuatorsetting, and RF input power setting.
 6. The non-transitory computerreadable medium of claim 2, wherein the at least one virtual wirelesscommunication system setting comprises a virtual wireless communicationsystem placeholder setting of a virtual placeholder component and avirtual wireless communication system existing setting of a virtualexisting component.
 7. The non-transitory computer readable medium ofclaim 6, wherein the at least one real setting of the signaldistribution equipment in the real wireless communication systemcomprises at least one real existing setting of real existing equipmentand at least one real placeholder setting of real placeholder equipment.8. The non-transitory computer readable medium of claim 7, whereinmodifying, by the OEM specific software system, the at least one realsetting of the signal distribution equipment in the real wirelesscommunication system based on the at least one virtual wirelesscommunication system setting in the at least one virtual wirelesscommunication system configuration file comprises: modifying, by the OEMspecific software system, the at least one real existing setting of thereal existing equipment electronically connected to the real wirelesscommunication system when the virtual wireless communication system isactivated based on the virtual wireless communication system existingsetting of the virtual existing component in the at least one virtualwireless communication system configuration file.
 9. The non-transitorycomputer readable medium of claim 8, wherein modifying, by the OEMspecific software system, the at least one real setting of the signaldistribution equipment in the real wireless communication system basedon the at least one virtual wireless communication system setting in theat least one virtual wireless communication system configuration filefurther comprises: modifying, by the OEM specific software system, atleast one real placeholder setting of real placeholder equipment basedon the virtual wireless communication system placeholder setting of thevirtual placeholder component in the at least one virtual wirelesscommunication system configuration file when the real placeholderequipment is electronically connected to the real wireless communicationsystem after the virtual wireless communication system is activated. 10.The non-transitory computer readable medium of claim 2, furthercomprising guiding, by the OEM specific software system, a user throughsetup of the signal distribution equipment in the real wirelesscommunication system for execution of the virtual wireless communicationsystem in the real wireless communication system.
 11. The non-transitorycomputer readable medium of claim 10, wherein the setup of the signaldistribution equipment comprises at least one of placement of realcomponents in a signal distribution equipment rack, placement of signaldistribution equipment modules within a real chassis, connectionsbetween the signal distribution equipment, and geographic placement ofthe signal distribution equipment for execution of the virtual wirelesscommunication system in the real wireless communication system.
 12. Thenon-transitory computer readable medium of claim 11, further comprisingalerting, by the OEM specific software system, the user if the signaldistribution equipment is improperly set up.
 13. The non-transitorycomputer readable medium of claim 11, further comprising alerting, bythe OEM specific software system, the user if the signal distributionequipment is properly set up.
 14. A method for implementing a livewireless communication system configuration from a virtual wirelesscommunication system design using an original equipment manufacturer(OEM) specific software system in a real wireless communication systemcomprising a plurality of remote units, comprising: configuring, by anOEM specific software system in a real wireless communication system, atleast one virtual wireless communication system setting for a virtualwireless communication system; enforcing, by the OEM specific softwaresystem, upon the at least one virtual wireless communication systemsetting OEM design constraints of at least one real setting of signaldistribution equipment in the real wireless communication system;generating, by the OEM specific software system, at least one virtualwireless communication system configuration file comprising the at leastone virtual wireless communication system setting for the virtualwireless communication system; storing, by the OEM specific softwaresystem, the at least one virtual wireless communication systemconfiguration file in memory at the real wireless communication system;and modifying, by the OEM specific software system, the at least onereal setting of the signal distribution equipment in the real wirelesscommunication system based on the at least one virtual wirelesscommunication system setting in the at least one virtual wirelesscommunication system configuration file, wherein configuring, by the OEMspecific software system in the real wireless communication system, theat least one virtual wireless communication system setting for thevirtual wireless communication system comprises importing the at leastone virtual wireless communication system setting for the virtualwireless communication system.
 15. The method of claim 14, whereinconfiguring, by the OEM specific software system in the real wirelesscommunication system, the at least one virtual wireless communicationsystem setting for the virtual wireless communication system comprisesmodifying the at least one virtual wireless communication system settingfor the virtual wireless communication system.
 16. A method forimplementing a live wireless communication system configuration from avirtual wireless communication system design using an original equipmentmanufacturer (OEM) specific software system in a real wirelesscommunication system comprising a plurality of remote units, comprising:configuring, by an OEM specific software system in a real wirelesscommunication system, at least one virtual wireless communication systemsetting for a virtual wireless communication system; enforcing, by theOEM specific software system, upon the at least one virtual wirelesscommunication system setting OEM design constraints of at least one realsetting of signal distribution equipment in the real wirelesscommunication system; generating, by the OEM specific software system,at least one virtual wireless communication system configuration filecomprising the at least one virtual wireless communication systemsetting for the virtual wireless communication system; storing, by theOEM specific software system, the at least one virtual wirelesscommunication system configuration file in memory at the real wirelesscommunication system; and modifying, by the OEM specific softwaresystem, the at least one real setting of the signal distributionequipment in the real wireless communication system based on the atleast one virtual wireless communication system setting in the at leastone virtual wireless communication system configuration file, whereinthe at least one real setting of the signal distribution equipment inthe real wireless communication system comprises at least one of an RFpath configuration, power amplifier setting, attenuator setting, and RFinput power setting.
 17. The method of claim 16, further comprisingguiding, by the OEM specific software system, a user through setup ofthe signal distribution equipment in the real wireless communicationsystem for execution of the virtual wireless communication system in thereal wireless communication system.
 18. The method of claim 17, furthercomprising alerting, by the OEM specific software system, the user ifthe signal distribution equipment is improperly set up.